What replacing SAP costs: how the budget breaks down and what inflates it

In short. Lifting a single process out of SAP into its own system is the entry point for this class of project. Replacing a working contour without the heavy modules costs two to four times that. A full replacement, with the integration bus and the warehouse, runs to around six times the entry point and upwards. Before any of it comes an audit, at between a third and a half of the entry-level project and three to six weeks of work, after which the rest stops being a range. A pilot of one key process takes six to ten weeks; a phased migration, six to twelve months.

We quote in roubles, so the figures below are given as proportions and timelines rather than converted amounts — convert at the rate of the day if you need an absolute number, or ask us for a quote.

A sixfold spread reads like a dodge, so what follows is what separates a project at the bottom of it from one at the top.

How the estimate breaks down

The proportions for replacing an ERP differ from building a system from scratch. There is less development and more data migration and stitching into neighbouring systems: the new system has to stand exactly where SAP stood.

Kind of work	Share of budget	What is inside
Inventory of functions and data	10–15%	Interviews, transaction-log audit, the replacement matrix
Development	35–45%	Rewriting the business logic, roles, interfaces, reporting
Integrations	20–30%	Banks, warehouse, accounting system, document flow, LDAP/SSO
Data migration	10–15%	Reference data, balances, open documents, archive
Launch and stabilisation	10–15%	Parallel track, reconciliation, training, fixes

Integrations take the largest share after development. That is the defining difference from a new build: in a new system the interfaces are designed, in a replacement they already exist, and they have to be found and described before anything can be moved.

Three scenarios

One process. A section with clear edges leaves SAP: procurement up to the approval stage, reference data and the product catalogue, warehouse accounting with no link to banking. The old system keeps running and the exchange goes both ways. Most first projects live here, because the company is testing a vendor on ground where a mistake does not stop the business.

A working contour. The main processes move and SAP stays in read-only mode for audit. A company that uses its ERP as an accounting core without deep industry customisation lands in this band. Eight months to a year and a half.

A full replacement. The contour with the integration bus, a warehouse on EWM, industry-specific calculations and information-security requirements. The budget here is set not by the ERP modules but by what hangs off them: the bus that carries half the company’s exchanges, and the warehouse that cannot be stopped over a weekend.

What inflates the budget quietly

The integration bus. SAP Process Orchestration gets remembered mid-project, when it turns out banks, marketplaces and production all run through it. A bus has no business value of its own, it cannot be moved in parts, and its licences are counted separately. An inventory of the exchanges before development usually shows a third of the interfaces are dead and a couple of live ones have neither documentation nor an owner.

The warehouse. Replacing SAP EWM is counted per site, not per function: you cannot run half a warehouse on the new system. Five warehouses mean five switchovers, each with its own stop and stocktake. If conveyors and sorters are driven through EWM, this is industrial automation, with different timelines and a different price.

Historical data. Moving everything costs twice: once in the migration and then forever in a bloated database. The split that works is two years of current data into the new system, deeper history into an archive environment with its own interface, and legally significant documents in full regardless of age.

The parallel track. For a month or two both systems run at once, data is written to both and reports are reconciled. That is double infrastructure and double load on people, and the line is often missing from the estimate. It is also the only insurance: a hard cutover without reconciliation almost always exposes discrepancies the audit did not find.

Information-security requirements. Segmentation, logging, operational documentation, certification. For regulated infrastructure this is a separate layer of work with no functional value and a visible share of the budget.

People on your side. No ERP replacement happens without employees who explain how the process actually works and accept finished parts on real data. Where nobody is assigned, the project does not grow in the estimate, it grows in the calendar: two-week gaps open between a finished part and anyone looking at it.

Why a fixed price before the audit is a bad sign

A number produced from a three-page description was sized whole, and sizing whole is wrong by a factor of two in either direction. Both directions hurt: too high and you pay for somebody’s buffer, too low and the vendor starts cutting what the client cannot see, with the tests and the documentation going first.

The order that works: a fixed-price audit of three to six weeks, delivering a function replacement matrix and a list of interfaces. After that the development estimate is built line by line. The audit output stays with you and can be taken to a different vendor. How to read such an estimate is covered separately in how to check a development estimate.

The year after launch

Running the new ERP costs roughly 15–20% of the development budget per year: hosting, updates, fixes and small changes as the process shifts. On top of that comes something SAP used to cover: the infrastructure is now yours, with servers, backups, monitoring and someone on call.

The saving is not the licence difference for one year. SAP licences are not being renewed, so the comparison is not against their price but against the risk of running a core system with no support and no security updates.

Common questions

Why a sixfold range instead of one number? Because until the inventory is done the main unknowns are unknown: how much of the functionality is in use, how much customisation has accumulated and how many external systems depend on the ERP. Two companies of the same size differ by a factor of three. The number appears after the audit.

Can it be done below the entry point? Sometimes, where the task really is narrow: one process, one role, no banking and no warehouse. More often a number below that line means the inventory and the data migration were taken out of the project, and they will have to happen anyway, later and at a higher price.

Is replacing Oracle costed the same way? “Replacing Oracle” hides three different projects: moving the database to PostgreSQL, replacing Oracle E-Business Suite as a business system, and infrastructure such as Exadata. The first is estimated by an inventory of the PL/SQL rather than by data volume, because the logic lives inside the database. The breakdown is in the phased replacement methodology.

How long does a project like this take? A pilot of one key process takes six to ten weeks, a phased migration six to twelve months, and a full exit for a large company one to four years. What drives that is covered in how long a SAP migration takes.

What if the licences have already stopped working? Then taking the old system out of the critical path merges with the migration: SAP stays read-only in a closed environment and the data remains available for audits and inspections. The order of stages is in migrating off SAP.

The rule

An estimate for replacing an ERP that contains no inventory of interfaces, no data migration and no parallel track was not costed for your project. Ask the vendor to add those three lines first, then compare totals. How we do this is on the SAP and Oracle replacement page.