Migration for 150 employees: a playbook without a big bang

A company of 150 people switches off the old system on a Friday evening and switches on the new one. On Monday half of the orders are stuck, the bookkeeping does not match the warehouse, and no one knows whether it is the data or a wrong setting. That is the big bang, and it rarely fails quietly. Large IT projects run 45% over budget on average and deliver 56% less value than promised. In 17% of cases the damage is large enough to threaten the survival of the company (McKinsey and Oxford, 2012).

A changeover for 150 employees does not have to be a gamble. You cut it into waves, let the old system keep running until each wave is stable, and decide after each step whether to continue. What follows is the order that works, with the places where teams get stuck.

Measure first, then build

The first mistake is choosing a supplier before you know what you are replacing. Start with a process audit: record how the work really flows today, which steps add value and which are only there because they have always been there. With 150 people there are dozens of processes running in parallel, and most of them are documented nowhere. What you do not map migrates along, including the duplicate work.

Lay a FinOps audit over your licences and infrastructure as well. Organisations waste 20 to 30% of their IT spend, and more than half of SaaS licences go unused (Flexera, 2024). That is money you do not need to carry over to the new platform. Every licence you cut and every system you switch off is a cost that stays away and one connection less to build.

Cut the migration into waves

A wave is a bounded piece of work that you move from the old system to the new one from start to finish: one module, one department or one process, with the associated data and users. You do not build everything at once. You choose a first wave that is small enough to oversee and important enough to prove something.

1. Start with a process that has a clear boundary, where the data is clean and the dependencies are limited. Order-to-cash or inventory management are often good first waves.
2. Place processes that depend on each other in consecutive waves so that a fault in one does not drag the other along.
3. Keep the process with the most exceptions and the dirtiest data for later, once the team knows the platform and has found its rhythm.
4. Give every wave the same fixed pattern: build, test with real data, run in parallel, and only then switch over.

Let legacy run: the parallel run

The big bang fails because there is no way back. A parallel run does have one. During each wave the old system keeps doing the work of record, while the new one runs the same work alongside it on the same input. You compare the outcomes day after day: the same invoices, the same balances, the same stock levels. Only once the new system gives the same result for a number of periods in a row do you move the source of truth. That costs a while of double work, and it buys you the right to fall back without damage.

And do not count on an AI to do the migration for you. Gartner expects that more than 70% of the mainframe exit projects starting in 2026 will not reach their goal, precisely because teams overestimate what generative AI can handle (Gartner, 2026). AI helps with reading old code and drafting test cases. It does not do the reconciliation, and it does not know your exceptions. Treat it as a tool, not as the contractor.

Migrate and reconcile data

Data migration is where most of the time disappears and where teams plan the least. Old systems are full of fields that someone once misused for something else, customers who exist three times over, and amounts in currencies no one uses anymore. You pull the data out, clean it, and load it in with a trail back to the source, so you can trace every record. Reconciliation is the core of every wave.

• Count the records on both sides and explain every difference, even a difference of one.
• Reconcile the amounts that matter down to the cent: outstanding receivables, inventory value, general ledger balances.
• Test with a copy of the real production data, not with made-up examples, because the exceptions are in the real thing.
• Have the owner of the process sign off on the figures, not the crew that ran the migration.

Bring 150 people along

A platform that is technically correct and that no one uses is a failed migration. With 150 people you are changing more than software. You are changing how people fill their day. Involve a handful of key users early per wave, let them help build the way their process runs in the new system, and make them the people who train their colleagues. Train per wave and close to the switch-over, so that what people learn is still fresh when they need it. One large training for the whole company, months before the first wave, is wasted time.

Cutover, module by module

The switch-over itself is small when the groundwork is right. Per wave you convert one module, at a moment with little traffic, with the old system still on standby. The users of that module move over, the rest of the company works on as it did yesterday. Once the first wave runs stably for a few weeks, the next one starts, with what you have learned worked into it. This way you build up the platform while the company keeps running, until the last module is over and the old system may be switched off.

The road to a new platform is not spectacular. It is a series of small, reversible steps, each with a way out. That is exactly why it arrives.

At the end there is one platform that you own, with the code in your own repository and without the lock-in that holds you hostage again next time. Whoever approaches a changeover this way trades one large risk on one evening for a series of small decisions that you keep in your own hands. That is the only version of this migration you would dare to do a second time.