Phased ERP delivery: how to go live module by module

Phased ERP implementation means going live one module at a time, in an order chosen for risk rather than for the org chart, with data migrated, people trained and a parallel run reconciled for each module before the old way is switched off. It is slower on paper than a big-bang go-live and far faster in practice, because big-bang projects tend to slip for months while every module waits for the least ready one. This article sets out how we sequence modules, what a per-module go-live involves, how long a parallel run should last, and what the client team has to do at each step.

Why big-bang ERP go-lives fail and phased ones do not

A big-bang go-live requires every module's data to be clean on the same day, every team to be trained in the same fortnight, and every integration to work the first time. One of those always fails, and because everything is coupled, the whole date moves. Meanwhile the business has frozen change requests for months and the people who will use the system have lost interest. When the system does go live, every problem arrives at once, the support queue overwhelms the project team, and the reputation of the ERP is set in the first week.

Phasing removes the coupling. Each module has its own date, its own data owner and its own success test. Problems arrive in small batches. The team that goes live first becomes the internal reference for the next, and the project earns credibility module by module rather than staking it all on one weekend. This is the same reasoning behind modernising without a rewrite; the strangler pattern applied to process rather than code.

ERP rollout plan: sequencing modules by risk

The exact modules vary by industry; a manufacturer's phase two is usually inventory, a builder's is lead management, a logistics operator's is the driver app and dispatch. The principle holds: start with the module that has the highest pain and the fewest dependencies, and never start with finance.

Modular ERP delivery: what one phase contains

Each phase is a complete small project with the same five steps, and the discipline is to finish all five before the next phase starts.

• Configure and build: the module is built or configured against the process as agreed in scoping, with the client's process owner reviewing weekly.
• Migrate data for this module only: extracted from the old system or spreadsheets, cleansed with the client's data owner, loaded to a test environment, checked, then loaded for real at cut-over.
• Train the team that uses it: by role, on their own data, in the week before go-live; not the whole company months ahead.
• Run parallel: both old and new processes run for an agreed period and the outputs are reconciled.
• Switch off and support: the old process stops, the project team stays close for two weeks, and the module moves to the Care Plan.

Data migration per module

Migrating data module by module is the single largest reason phasing works. Cleansing the item master is a finite job for one person with a deadline; cleansing every master and every open transaction at once is a job nobody finishes. Each phase migrates what it needs, in a repeatable script, tested on a copy first. Open transactions at cut-over are the awkward part: we usually close what can be closed, migrate the remainder with their original references, and reconcile them explicitly. The data migration for platform implementations article covers the mechanics.

The parallel run: how long and what to reconcile

A parallel run means the team does the work twice, in the old system and the new, for long enough to prove they match. That is a real cost, so the run has to be as short as the risk allows. For an inventory module, two to four weeks with a weekly stock reconciliation is typical. For finance, one full accounting period, because the test is the trial balance and the GST return. For lead management, a fortnight is often enough, because the risk is low and the old process is a spreadsheet.

Reconciliation is defined before the run starts: which report from each system, compared how often, by whom, and what tolerance counts as a match. Every difference is investigated and classified as a data error, a process difference or a bug. The old process is switched off only when a full reconciliation cycle produces no unexplained differences. Skipping this step is how ERPs go live with stock figures nobody trusts.

ERP go-live strategy: the client side of the work

Phasing only works if the client provides three things per module: a process owner who can decide how the module should work and who is available weekly; a data owner who cleanses that module's masters and signs off the migration; and the users' time for training and the parallel run. When the second module starts, the first module's users become the advocates and often the trainers. We plan the phases around the business calendar: no finance cut-over at year end, no dispatch cut-over in a peak season, no academic-record cut-over during admissions.

A worked example

A university ran a decades-old ERP for student records, fees and finance, with the staff who knew it approaching retirement. A rewrite had been proposed twice and abandoned. The phased approach started with master data: programmes, courses, fee structures and the student master, mapped from old codes to new. Phase two was admissions, chosen because it had a natural cut-over point before the intake and involved one office. It ran parallel with the old process for that intake, with applicant counts and fee receipts reconciled weekly. Phase three moved student records and fees for the enrolled cohort, timed for the semester break. Finance integration came last, with a parallel period reconciled against the trial balance. Each office was trained just before its own go-live, and the admissions team ran the sessions for registrars. No module went live during examinations or admissions. The full account is in the university ERP modernisation case study.

Team and timeline

A phased implementation needs a delivery lead who owns the phase plan and reconciliation, two to three engineers, a data migration engineer who is on the project from phase one, and a trainer or the engineers themselves for role-based sessions. On the client side, a project sponsor plus one process owner and one data owner per module. Each phase typically runs six to twelve weeks including its parallel run, and phases can overlap: build for phase three starts while phase two is in its parallel period.

The phase plan itself is produced in a Sprint Zero, ten working days at $3,250 / ₹2,00,000, credited to the build. Delivery runs under ERP and CRM development from $28,000 / ₹18.4L per phase, or as ReCore when an existing ERP is being modernised rather than replaced, at $31,500–105,000+ over eight to sixteen weeks per program. Each phase is fixed in price and date. After each go-live, the module moves to a Care Plan; see the pricing page for the tiers.

Before you start: a checklist

• Rank modules by pain and by number of dependencies, and choose phase two accordingly
• Name a process owner and a data owner for each module before scoping
• Map the business calendar and block the dates when no cut-over may happen
• Define the reconciliation report, frequency and tolerance for each parallel run
• Decide how open transactions at cut-over will be handled
• Plan training by role in the week before each go-live, on real data
• Agree who supports users in the two weeks after each switch-off
• Write down what "done" means for each phase and get it signed

Glossary

• Cut-over: the moment a module's transactions start in the new system
• Parallel run: operating old and new processes simultaneously and reconciling the outputs
• Master data: the reference records such as items, customers and accounts that transactions depend on
• Open transactions: orders, invoices or cases not yet completed at cut-over
• Reconciliation tolerance: the agreed difference below which two systems are treated as matching
• Process owner: the client person who decides how a module should work and signs it off

Related reading

See custom ERP for manufacturing, why enterprise software implementations fail on adoption and our enterprise platform implementation service. Martin Fowler's note on the strangler fig application is the primary reference for incremental replacement.

Go live in small steps, reconcile before you switch off, and let each module's team make the case for the next.