Skip to main content
Schedule Call With Us
ERP Migration and Upgrade

Move to a New ERP, or Upgrade the One You Already Run

These are two different projects with two different risk profiles. Replatforming means deciding what data deserves to come with you. Upgrading means finding out what your customisations will cost. We run both with reconciled numbers, a rehearsed cutover and a rollback position that has been tested.

50+ ERP and software projects. Zero failed projects since 2021.

Book a Free Consultation → Features
Cutover Runbook
Illustrative
H-36
Transaction freeze in the old system
Owner: operations lead
H-30
Final extract, transform and load
Owner: data lead
H-20
Reconcile trial balance, stock and open items
Owner: finance controller
H-12
Go or no-go decision
Owner: steering group, named in advance
H-6
Interfaces, printing and access switched over
Owner: IT lead
H-0
Business opens on the new system
Owner: process owner per area
Rollback stays available and tested right up to the go or no-go point.
4-9 mo
Typical mid-market replatform
6-16 wk
Typical version upgrade
2
Dress rehearsals before cutover
0
Failed projects since 2021
Why It Matters

Two jobs that get confused with each other

Replatforming and upgrading share a cutover weekend and almost nothing else. Scoping them as one project is how both go wrong.

Replatforming

Moving to a different ERP is a decision about what you leave behind

The hard part is not writing the load scripts. It is agreeing which records earn a seat on the new system. Most organisations try to carry everything, then spend months mapping history that nobody will ever query. Open items, balances and a defined window of closed transactions is usually the right answer, with the old system kept read-only for audit.

  • Scope of carried data agreed and signed before mapping starts.
  • Old system retained in read-only mode for statutory access.
  • Reconciliation as the gate, not a formality at the end.
A finance team deciding which ERP records to migrate to a new system
Version Upgrades

Your customisations are what make an upgrade expensive

The version change itself is rarely the problem. The cost sits in proving that every modification, report, workflow and integration you built still behaves against your own processes. Organisations defer upgrades because of that bill, then pay a larger one later, because falling out of support means security exposure and every skipped version makes the next jump harder.

  • A full inventory of modifications, reports and interfaces first.
  • Retire, replace with standard, or carry forward and retest.
  • Automated regression tests that make a regular cadence affordable.
Reviewing ERP customisation and integration code before a version upgrade
What Moves

The six things that have to come across

Each category is scoped, cleansed and reconciled on its own terms. Treating them as one bucket called "the data" is where migrations lose control.

📋
Master data
Customers, suppliers, items, bills of material, price lists and employees. This is where deduplication and format standardisation pay for themselves, because every transaction points at it.
📜
Open transactions
Unshipped sales orders, open purchase orders, work orders in progress and unapplied receipts. These are non-negotiable: the business cannot trade on Monday without them.
💰
Balances and ledgers
Opening trial balance, chart of accounts mapping, receivables and payables ageing, and tax positions. The trial balance has to agree with the old system to the currency unit.
📦
Stock and valuation
Quantities by warehouse and bin, lot and serial records, and the valuation method with its resulting value. Quantity matching is easy. Valuation matching is where migrations stall.
📄
Documents and history
Closed transactions inside the agreed window, plus attachments, contracts and signed documents. Anything outside the window stays in the read-only archive rather than being dragged forward.
⚙
Configuration and access
Tax rules, approval workflows, numbering series, report layouts, integrations and user roles. Rebuilt deliberately on the new version rather than copied over without review.
How It Works

Five stages, whether you are replatforming or upgrading

1
Assessment
We inventory data volumes, customisations, integrations and reports, and set the scope of what moves.
2
Cleanse and map
Deduplication, format standardisation and mandatory gaps filled, then field by field mapping rules.
3
Rehearse
At least one full dress rehearsal on production-like data, timed end to end, with reconciliation run.
4
Test and reconcile
Regression testing against your processes, and balances, stock and open items agreed with finance.
5
Cut over
The runbook is executed with named owners, a go or no-go gate, and support through the first close.
What Is Included

Everything a migration or upgrade covers

🔍

Scope and data assessment

What moves, what stays, how much history, and what the old system keeps doing after cutover.

🧹

Data cleansing

Deduplication, format standardisation and mandatory gaps filled before loading, not after.

🔄

Mapping and load scripts

Repeatable, versioned extract and load routines, so a rehearsal can be run again without hand work.

⚖

Reconciliation pack

Trial balance, stock valuation, receivables and payables compared line by line against the old system.

🧪

Regression testing

Your own processes tested against the new version, with automation for the tests you will rerun.

📋

Cutover runbook

Timed steps, named owners, a go or no-go gate and a rollback path that has actually been executed.

What Changes

What a planned migration gives you

Clean
Data from day one
Agreed
Definition of correct
One
Weekend of downtime
Tested
Rollback, not assumed
In
Vendor support again
Regular
Upgrade cadence, not jumps
Choose A Platform

Already know which ERP you are moving to or upgrading?

The method above is the same everywhere. What differs is the tooling, the upgrade path and what the vendor supports.

ERPNext
Migrating off spreadsheets, Tally or an ageing system, or moving between Frappe versions where patches and custom apps decide the upgrade effort.
See the ERPNext page →
Odoo
Annual releases mean upgrades come round often, and custom modules plus Studio changes are what determine whether the jump is routine or painful.
See the Odoo page →
SAP
Larger data volumes, stricter audit expectations and a real choice between a clean rebuild and a technical conversion of what you already run.
See the SAP page →
Why Us

Why teams trust us with a cutover weekend

1
We define correct first
The reconciliation targets are agreed in week one, so the data has something firm to be tested against.
2
We argue for less history
Carrying twenty years forward costs money and adds risk. We say so, and we set up the read-only archive instead.
3
We rehearse properly
At least one full dress rehearsal on production-like data, timed end to end, before anyone commits to a date.
4
We test the rollback
A rollback plan that has never been executed is a hope. Ours is run during rehearsal and timed like any other step.
5
We are honest about downtime
A weekend window, stated up front. We would rather lose the argument early than the trust on cutover night.
6
Proven delivery
50+ ERP and software projects across industries, with zero failed projects since 2021.
FAQ

ERP migration and upgrade questions

How much historical data should we bring across?
Less than you think. Open items, current balances and two to three years of closed transactions covers almost every operational and reporting need. Everything older belongs in the old system, kept running in read-only mode for audit and statutory access. Most organisations try to carry twenty years forward, which multiplies the mapping work, the reconciliation effort and the risk, in exchange for records nobody opens.
How long does an ERP migration take?
A mid-market replatform from one ERP to another runs 4 to 9 months, depending on how many entities, warehouses and integrations are in scope. A version upgrade of the ERP you already run is a different size of job: 6 to 16 weeks, driven almost entirely by how much customisation has to be regression tested. We size both against your actual system before quoting.
How much downtime should we plan for?
Plan for a weekend. A realistic cutover window runs from a Friday evening transaction freeze to Monday morning opening, and the reconciliation in the middle of it is what takes the time, not the data load. Anyone promising zero downtime on an ERP cutover is either redefining downtime or has not reconciled the numbers yet.
Can we migrate without stopping the business?
Not entirely, but the freeze can be kept short. A parallel run, where transactions are entered in both systems for a defined period, gives you a comparison and a fallback. It also costs real effort because your team is doing the work twice, so it should be time-boxed to two to four weeks on the highest risk processes rather than run open-ended across everything.
What happens to our customisations when we upgrade?
Each one gets assessed: retire it, replace it with standard functionality that now exists, or carry it forward and retest it. Customisation debt is what makes upgrades expensive, not the version change itself. We inventory every modification, report and integration first, because that list is the real scope of the project and the real cost is regression testing it against your own processes.
How do you prove the migrated data is correct?
By agreeing what correct means before we start. Trial balance, stock quantity and valuation, open receivables and payables, and open order counts are reconciled line by line against the old system, and the sign-off gate is that they agree. The riskiest part of a migration is not the software, it is defining correct late, so reconciliation has nothing firm to test against.

Plan Your Migration or Upgrade

Book a free consultation. We will look at your current system, the data volumes and the customisations you carry, and tell you whether you are looking at a 6 week upgrade or a 6 month replatform.

Book a Free Consultation →

No commitment. A straight read on scope, timeline and cutover risk.

ERP Migration and Upgrade Features

What Is Inside an ERP Migration or Upgrade

A migration is a data project with a deadline attached to a weekend. Here is how we scope what moves, how we clean it before it goes anywhere, how we prove it landed correctly, and how the cutover itself is rehearsed before the real one.

Core Features

From scoping the data to a cutover that holds

Scope and Cleansing

Migration is the one honest chance to leave bad data behind

Before anything is mapped, we agree how far back the history goes and what stays in the old system as a read-only archive. Then we clean what is left: duplicates merged, address and tax formats standardised, mandatory fields filled. Doing this after go-live means doing it in a live system with people working in it, which is why the organisations that skip it regret it.

  • History window agreed and signed before mapping starts.
  • Deduplication and format standardisation before load, not after.
  • Old system retained read-only for audit and statutory access.
Reviewing and cleansing master data records before an ERP migration
Reconciliation and Testing

Nothing is signed off until the numbers agree

The reconciliation pack compares trial balance, stock quantity and valuation, and open receivables and payables against the source system. On an upgrade, the equivalent gate is regression testing: every customisation, report and interface run against your own processes, with the tests automated so the next upgrade costs a fraction of this one.

  • Reconciliation targets defined in week one, not at the end.
  • Regression suites built around your processes, not generic scripts.
  • Time-boxed parallel run on the highest risk processes.
Reconciling trial balance and stock valuation between two ERP systems
Rehearsal and Cutover

The real cutover should be the second or third time you have done it

We run at least one full dress rehearsal on production-like data, preferably two, timed end to end so the weekend window is a measured number rather than a guess. The runbook names an owner for every step, fixes a go or no-go point, and includes a rollback that gets executed during rehearsal so you know it works and how long it takes.

  • One dress rehearsal minimum, two where volumes are large.
  • A go or no-go gate with a named decision group.
  • Rollback executed and timed, not written down and assumed.
A project team walking through an ERP cutover runbook rehearsal
What You Get

Everything the project delivers

🔍

Scope and history decision

A written record of what moves, what stays, and how the old system is kept available afterwards.

🔄

Versioned load routines

Repeatable extract, transform and load scripts, so a rehearsal can be rerun without manual work.

⚖

Reconciliation pack

Balances, stock valuation and open items compared side by side, with the variances explained.

🧪

Regression test suite

Your processes captured as repeatable tests, which is what makes a regular upgrade cadence affordable.

📋

Timed cutover runbook

Every step with an offset, an owner, a dependency and a tested rollback position.

📚

Handover documentation

Mapping rules, archive access notes and an upgrade plan, so the next version is a routine job.