ERP implementation: stages, timelines and where projects fall apart

An ERP implementation is a project in which a company moves accounting, purchasing, warehousing, production and finance into a single landscape with shared reference data and shared rules: process discovery, design, configuration and custom development, data migration, training, pilot operation, go-live and support. The median project runs 9 months — that is the figure from Panorama Consulting Group, based on 170 organizations with a median annual revenue of $200.5 million (data collected from January 2025 to January 2026). 30% of projects went over budget and 22.3% over schedule. The technology is the least common breaking point. Of those who missed the schedule, 57.9% explain it by organizational causes and 50% by technical ones. In budget overruns, expansion of the original scope of work (51%) is named more often than technical problems (43.1%), while organizational issues (39.2%) and the state of the data (29.4%) carry comparable weight.

Below are the stages without the vendor gloss, and what stands behind each of them in a company that is already running. How long a project takes and why the measurements range from nine months to five years. Why the budget drifts and which cost items usually never make it into the estimate. What dirty reference data does to the migration of balances. Why you need a parallel run and how to get out of it. Who is responsible for the system after go-live, and why without that answer the effect of the project melts away. Plus the Russian frame that Western playbooks do not have: systems losing vendor support, the state of domestic platforms, and the question of what happens to the project if the vendor changes.

What stages does an ERP implementation consist of?

Short answer: the list of stages is the same at every integrator; the difference is in what is accepted as the result of each one.

The right-hand column is what the project is actually about. A stage closed with an empty document comes back two steps later: uncleaned reference data surfaces during migration, an undocumented exception during pilot operation, a missing owner during the first period closes after go-live. We covered the moment when spreadsheets and an accounting package stop coping and the conversation about a single landscape becomes concrete in a separate piece — when a business should move off Excel.

How long does an ERP implementation take and why do timelines drift?

Short answer: a median of 9 months, complex landscapes take years, and schedules most often slip for organizational reasons.

Start with the baseline figure. According to The 2026 ERP Report from Panorama Consulting Group, the median project runs 9 months. Within the sample, 58.8% finished on schedule, 18.8% finished earlier than planned, 18.2% slightly late and 4.1% significantly late.

Russian integrators quote a different order of magnitude for complex landscapes: according to a ComNews piece dated February 24, 2026 (by Alexey Mikolenko), complex implementations take three to five years. The numbers are not directly comparable: Panorama gives a median across the whole sample, ComNews an estimate for complex projects. The gap most likely comes down to scope: a single landscape for a single legal entity and a group of companies with consolidation, several production sites and a dozen adjacent systems are different objects.

Panorama collected the reasons for schedule slippage from those who ran late:

The first line means sign-offs, arguments about internal rules and resistance to standardization. Alexey Telkov, CEO of the Galaktika corporation, in the same ComNews piece calls missed deadlines and budgets the most common problem on large implementations and ties it to how detailed the planning is and how the project is broken into phases.

The picture is similar in global migrations. Information Services Group surveyed 200 senior executives at large companies: according to a CNews publication dated February 6, 2026, 60% of those who committed to moving to SAP's new platform missed their deadlines and exceeded their budgets, and 49% of companies do not redesign their processes at all, preferring to keep the existing ones. ISG lead analyst Michael Dornan explains this as an attempt to get through the transition as fast and as cheaply as possible, and adds: "In many cases the delays are caused by people, not technology."

Why does an ERP implementation go over budget?

Short answer: the estimate falls apart on what was never in it — additional systems, scope expansion and putting the data in order.

Panorama broke overspend down by cause among the 30% who exceeded their budget: additional technologies that had to be bought to meet the project's goals — 54.9%; expansion of the original scope — 51%; technical problems — 43.1%; organizational ones — 39.2%; underestimating the number of people on the project — 35.3%; underestimating the cost of consultants — 31.4%; data problems — 29.4%.

The first line usually means an architectural mismatch that was missed during selection: the standard reporting does not hold up at the required volume, exchange with neighbouring systems has to be built as a separate layer, analytics has to be moved into a separate environment. How that connective layer is built and what it costs is covered in the article on system integration.

One cost item fits into none of these lines and is bigger than many of them: the time of your own staff. Describing processes, cleaning reference data, reconciling balances and accepting stage deliverables are done by people who are simultaneously closing the month and shipping orders. Russian surveys say this outright: in the Korus Consulting group's study "ERP today: priorities and barriers", presented on February 24, 2026, the main barriers to ERP projects are a limited budget (28.2%), a lack of expertise (14.1%), employee resistance (14.1%) and integration difficulties (11.3%).

Industry forecasts remain harsh. Gartner predicts that by 2027 more than 70% of recently implemented ERP initiatives will not fully meet the goals of their original business case, and up to 25% will fail catastrophically. That is a forecast rather than a measurement, but it describes a familiar situation: the system works, the money is spent, and nobody can show the promised effect in numbers.

What breaks an implementation inside a working company?

Short answer: reference data, balances, and the exceptions the standard configuration has no place for.

Dirty reference and master data. The same item is entered three times under different names, a counterparty exists in four records, units of measure are mixed up, and half the fields are filled in as free text. As long as each department worked in its own program, this was tolerable. In a single landscape every duplicate turns into a discrepancy between reports, and the cleanup has to be done by people who know the subject matter — that is, the same people who keep the current work running.

Migrating balances. It is not only records that move, but state: warehouse balances, open orders, settlements, prepayments, reservations. This is where everything that was papered over with manual corrections for years comes out. Data problems were named as a cause of overspend by 29.4% and as a cause of schedule slippage by 36.8% of Panorama's respondents, and those are the percentages that almost never get their own line in the project plan.

Exceptions the standard configuration has no place for. Your own discount approval scheme, shipping without prepayment for ten customers out of three hundred, misgrading that is settled "as agreed", a partial return with documents reissued. In discovery these cases surface last, because inside the company nobody considers them a process.

The immaturity of the processes themselves. Oleg Elmanov, CEO of Fusion, in the ComNews piece names immature and inconsistent internal processes, weak management initiative and insufficient preparation for change as the barriers. That is the part of the work you cannot buy together with the licences.

Do you need a parallel run with two systems going at once?

Short answer: you need it where the cost of an accounting error is higher than the cost of double entry — and always with an exit criterion written down in advance.

First, about the go-live approach. According to Panorama's 2026 data, 37.6% of companies use a hybrid approach, 30% go live in phases module by module, 15.9% switch over all at once, and 8.2% each roll the system out by location and by business unit. A single switchover is cheaper on the calendar and more dangerous in its consequences: if the first period close does not reconcile, there is nowhere to roll back to.

A parallel run is a compromise that people pay for. Documents are entered into two systems, discrepancies are worked through by hand, and the load on accounting and the warehouse doubles at the most stressful point of the project. The longer it lasts, the lower the quality of data entry in both systems: people start treating one of them as the "real" one and the other as a formality.

A working setup looks like this. Only the areas with a high cost of error are run in parallel: statutory accounting, customer settlements, inventory balances. A measurable exit criterion is written down in advance — for example, three consecutive closed weeks where discrepancies in balances and settlements stay below an agreed threshold. And the period has a hard end date, after which the decision goes up the chain rather than being postponed another month.

Who is responsible for the system after go-live?

Short answer: without a process owner inside the company, the system drifts back to the original mess over time.

Panorama states the report's main conclusion plainly: choosing a vendor matters, but the real difficulty is making the organization work differently once the new system is already in place. The same data shows the imbalance in preparation: only a minority of organizations work intensively on change, while most limit themselves to moderate effort.

The market is realizing this late, but it is realizing it — you can see it in what companies go to external consultants for. In the 2026 measurement, 50% of organizations asked for help with process work, 46.8% with change management, and 42.1% with support and realizing the benefits after go-live. That last line is exactly the work that begins where the implementation contract ends.

Evgeny Zavyalov, head of the Business Applications department at Reksoft, calls engagement and support from business users one of the hardest parts of the work in ERP projects. In practice that means three things: the process has an owner with the authority to decide how it works; every reference data set has someone responsible for maintaining it; and the system has a budget for development after handover. Why a system somebody paid for fails to take root with people is something we examined in detail on an adjacent class of systems — why CRM fails to take root. The mechanics are the same.

What is specific to Russia in this kind of project?

Short answer: the timeline is set not only by business logic, but by systems losing vendor support, the state of domestic platforms, and the question of what happens to the project if the vendor changes.

End of support as a deadline. In the Korus Consulting study, 24.1% of the companies surveyed run 1C:UPP, a legacy manufacturing configuration of 1C, the accounting and ERP platform most Russian companies are built on. The vendor announced the dates in advance: information letter No. 30064 dated December 9, 2022 states that configuration updates are released through the end of 2026, in Q1 2027 only if they are required to file 2026 reporting, and consulting on UPP stops on April 1, 2027. Such a date sets a deadline but not a scope of work: moving everything "as it was" will reproduce every accumulated workaround in the new system along with it.

The state of domestic platforms. ANO NTsK ISU surveyed 11 corporations with a combined 2024 revenue of 28.5 trillion rubles. According to a CNews publication dated May 20, 2026, the main barriers named were missing functionality and weak performance under load in Russian resource management systems, and "the problem is not the absence of modules, but the insufficient depth of their implementation". The cost of replacement over 2022–2025 is estimated there at 90–130 billion rubles, and the centre's CEO Kirill Semion described the situation this way: "What took Oracle or SAP decades, we are trying to 'sprint' through in five years." For planning this means one thing: you test the depth of the module you need on your own data before signing the contract, not during the demo.

Where the data sits. An ERP landscape ends up holding personal data of employees and customers, and with it the requirements of Federal Law 152-FZ, Russia's personal data protection law. What can go to an external service and what stays inside the perimeter is decided before design work starts, because the architecture depends on it. The boundary is examined in the article on using neural networks without leaking data.

A change of vendor mid-project. The risk is practical: part of the team leaves, and the knowledge of your custom development stays in other people's heads. The defence is technical rather than legal — you own the process descriptions, the data model, the source code of the custom work and the decision log. Without those artefacts, changing contractor means running discovery all over again.

What does it take for an implementation not to fall apart?

Short answer: six things assembled before the first contract — and half of them are not about IT.

1. A documented process, exceptions included. The real way of working, not a diagram of "how it should be": what happens on a return, a misgrading, an urgent shipment, a prepayment and a partial payment. That same description becomes the acceptance criterion for the stage.
2. A reference data audit. Items, counterparties, contracts, units of measure: how many duplicates there are, how many entries have nobody responsible for them, which fields are filled in as free text. Cleanup starts before the project starts, not in migration week.
3. Access to your own data. Exports of balances, orders and settlements in machine-readable form. If one person extracts that data by hand, the migration becomes a separate project inside the project.
4. A list of integrations. Accounting system, bank, marketplaces, warehouse equipment, document flow, cash registers. Every connection is separate money, a separate risk and a separate owner on the contractor's side.
5. Access rights. Who sees cost price, who sees purchase prices, who sees employees' personal data. Decided before design work: rights affect the data structure, not just the interface.
6. An owner after go-live and a support budget. Someone inside the company with the authority to decide how the process works, and money to develop the system over a three-year horizon.

The first three points are about the business, not IT, and they are exactly the ones most often skipped: comparing proposals is more interesting than writing down your own way of working. Which numbers a finished landscape owes the manager after go-live is covered in the piece on management reporting; without an answer to that question there is nothing to measure the project's effect with.

When does an off-the-shelf ERP fail to cover the job?

Short answer: when the amount of custom development for your exceptions starts to exceed the amount of out-of-the-box logic.

An off-the-shelf product sells a ready-made operating model. As long as your rules, reference data and access rights match the standard ones, the deal is a good one: you pay for proven logic and you do not pay to build it. Divergence starts at the exceptions — your own discount approval order, your own reservation rules, your own incentive calculation, your own roles in document flow. Configuration covers the first few divergences; after that the changes sit on top of someone else's architecture, and every vendor update has to be retested from scratch. This is exactly the mechanism behind the "additional technologies" line among the causes of budget overrun: the mismatch is discovered late and closed by buying more.

The workable answer is more often a hybrid. Statutory accounting lives on the platform, while the area that gives the company its advantage is built separately and connected through data exchange. That is what we did in a wholesale case: order intake and stock reservation moved into a separate system with two-way integration to 1C. Orders started being processed in minutes instead of hours, and the accounting system stayed where it was. We examined the fork between a ready-made product and a system built around your own process separately — your own system or an off-the-shelf one. How the types of landscape themselves are built and how they differ in cost of ownership is covered in the breakdown of ERP system types.

We work under contract and keep data inside Russia: we build ERP and CRM landscapes, integrations and AI agents around a company's specific process, and after handover we take the system on under a support contract. A conversation about implementation starts not with choosing a platform but with your specifics: what the exceptions in your reference data are, what happens at month-end close, who becomes the process owner after go-live. If that conversation is relevant right now — tell us about the task: we will go through your processes and size up the work area by area.

Sources

• Panorama Consulting Group, The 2026 ERP Report — 170 respondents, data from January 2025 to January 2026, a median project length of 9 months, budget and schedule adherence, causes of overspend and delay, go-live approaches, demand for external help and work on change management
• CNews, February 6, 2026. ISG study on migration to SAP S/4HANA — a survey of 200 senior executives, 60% of projects over budget and over schedule, 49% with no process redesign, comment by Michael Dornan (the fieldwork period is not stated in the publication)
• CNews, February 24, 2026. Korus Consulting group study "ERP today: priorities and barriers" — 43% of companies with an incomplete implementation or one that needs optimizing, 24.1% on 1C:UPP, project barriers
• The 1C company, information letter No. 30064 dated December 9, 2022 — 1C:UPP updates through the end of 2026, Q1 2027 only for 2026 reporting, consulting ends April 1, 2027
• ComNews, February 24, 2026. "Almost half of companies are 'not on good terms' with ERP" (Alexey Mikolenko) — complex implementations taking 3–5 years, comments by Alexey Telkov (Galaktika), Evgeny Zavyalov (Reksoft), Oleg Elmanov (Fusion)
• CNews, May 20, 2026. Barriers to ERP import substitution according to ANO NTsK ISU — a survey of 11 corporations, depth of module implementation, costs of 90–130 billion rubles, quote from Kirill Semion
• Gartner, What IT Leaders Must Do to Avoid Disappointing ERP Initiatives — forecast: by 2027 more than 70% of recently implemented ERP initiatives will not meet the goals of their original business case, and up to 25% will fail catastrophically (no publication date is given on the page; the material was checked on September 15, 2026)