“Let's run the old and new systems together for three months first. Safer that way.” You hear this a lot in project meetings. Usually from the owner or the finance manager. The intent is good: the new system hasn't proven itself yet, so running both gives you a way back if something goes wrong. But three months later, this is usually what you get: staff enter every order twice and leave work later and later. The numbers in the two systems stop matching, and no one can say which one is right. Everyone quietly treats the old system as the real record and the new one as homework. On the day the parallel period ends, the data in the new system can no longer be trusted, so it gets extended another month.
I'm Johnny Yang, founder of Brightstream Technology in Taiwan. In seven years I've handled more than 252 projects across more than 32 industries, and we deliver over NT$20,000,000 in custom-built systems a year. Whether a system turns out well is often decided in the week of the cutover.
A longer parallel run is not a safer one. My recommendation: run in parallel for exactly one full business cycle. For most companies that is one month-end close, one full pass from order entry, shipping and invoicing to closing the books. And don't enter every order twice. Only check the points that affect money and inventory, such as daily shipment counts, receivables and inventory balances. Before the parallel run starts, write two things down: the conditions under which you shut off the old system, the situations in which you fall back to it, and who makes those calls. Cutover week is about freezing master data, counting opening balances, switching the old system to read-only and reconciling every day. Not figuring it out as you go.
Why does instinct say the longer the better?
Let me start on your side. Wanting a longer parallel run is the right instinct. The scariest thing about switching systems isn't that the new one has bugs. It's that the new one calculates something wrong and you don't notice. Wrong shipment quantities, wrong receivables, wrong inventory. If those errors run for a month with nothing to compare against and you only find them at month-end, chasing them down is painful. A parallel run buys you a control group.
The problem is that parallel running has a cost, and the cost grows over time.
The first cost is labor. Entering every order twice isn't just double the work. On the second entry people get distracted, cut corners, skip orders. The second cost is trust. When the two systems disagree, people will always trust the old one, because it's familiar. The new system gets labeled “inaccurate” before it has even officially gone live. The third cost is that the fallback becomes a crutch. As long as the old system is still open, someone will refuse to fully move over. It's the same psychology as buying a system while your staff keep quietly using Excel.
So the real question isn't whether to run in parallel. It's what to run in parallel, for how long, and when to call it.
How much does a parallel run cost? A worked example
Owners rarely count this labor when they decide on a parallel period. Let's run the numbers on a hypothetical.
| Assumption | Value | Notes |
|---|---|---|
| Company size | 60 people | Assumed |
| People entering orders in both systems | 10 people | Sales support staff, warehouse staff, accountants and others who create documents; assumed |
| Extra time per person per day | 1.5 hours | Second entry plus checking differences; assumed |
| Working days per month | 22 days | Assumed |
| Extra hours per month | 330 hours | 10 × 1.5 × 22 |
| Equivalent headcount | About 2 full-time staff | Based on about 170 hours per person per month |
Under these assumptions, one month of parallel running is like hiring two extra people. Three months is six person-months. That's before overtime pay, before the orders entered wrong because people are tired, before the cost of everyone growing more resentful of the new system.
Once you run the numbers, you see the parallel period isn't insurance. It's a real expense. Worth spending, but spend it where it counts.
Four cutover approaches and which companies they fit
Parallel running isn't only “enter everything twice.” I group the common cutover approaches into four. Most companies are actually best served by the second one.
| Approach | How it works | Best for | Risk and cost |
|---|---|---|---|
| Full parallel | Every document entered in both old and new systems | Low document volume, strictly regulated operations | Highest labor cost, tends to drag on |
| Key-point checks | New system is primary; only key numbers compared daily | Most companies with 20 to 200 people | Moderate cost; checkpoints must be defined in advance |
| Phased go-live | Switch in batches by module, department or site | Companies with many sites or very different processes | Two data sets must be bridged in between |
| Direct cutover | Old system shut off on a set date | Old system barely used, or very simple data | Lowest cost; nothing to compare against if something goes wrong |
Key-point checks means this: all daily work happens in the new system. The old system is only used to produce comparison numbers, or you derive them from opening balances plus each day's key transactions. Every day you compare a fixed set of numbers, such as that day's shipment count and value, new receivables, and inventory balances for a few key items. If they match, keep going. If they don't, find out why that same day.
This way, staff don't enter every order twice, and you still have a control group. The checking is concentrated on one or two people, usually the accountant or the project lead, instead of spread across everyone.
What numbers do you compare each day?
Not many. Pick the ones that affect money and inventory. I usually suggest starting with these: on the sales side, that day's order count and value; on the warehouse side, that day's shipment count and inventory balances for a few high-value, fast-moving items; on the finance side, that day's new receivables and payables. If you manufacture, add that day's finished goods received into stock.
Assign one person to check each number. Log differences on a single list, with the cause and how it was handled. After a week, that list is your best acceptance record: if differences keep shrinking and every cause can be traced, the new system can be trusted.
If your company has several sites or business units, a phased go-live is also common. Switch one site, get it running smoothly, then switch the next. On sequencing, the rule is to switch first the part with the simplest process that best represents daily work, so the team builds experience.
How long to run in parallel? Three things decide it
There's no standard answer for how long, but there are three things to judge by.
First, the business cycle. The parallel run should cover at least one full cycle, so every major document type goes through at least once. For most companies the cycle is one month, because month-end close ties together order entry, shipping, invoicing, collections and costing in one pass. If your business has clear quarterly closes or special processes, such as distributor bonuses settled once a quarter, make sure those have at least been run in the test environment.
Second, data risk. Data involving money and inventory needs strict checking. Data that's only for internal reference, such as visit logs, can be cut over directly with no parallel run.
Third, how proficient the team is. If pre-launch training was solid and staff have already worked through real scenarios in the test environment, the parallel period can be much shorter. I wrote about how to schedule training so it works, covering the four weeks before and after launch, in How to run ERP training people actually use.
Write down the conditions for shutting off the old system before you start
The most common reason a parallel run drags on is that no one ever said when it ends. Before it starts, I have the owner and the project lead write down the shutoff conditions together, for example:
- One month-end close completed, with receivables, payables and inventory balances in the new system matching the comparison numbers, and every difference traced to a cause.
- No unexplained differences in daily checks for a consecutive period (number of days agreed by both sides).
- Every major document type has gone through at least one full process in the new system.
- Key users can do their daily work on their own, without project staff standing next to them.
When the conditions are met, the person designated in advance makes the call to shut off the old system. No further discussion. Without written conditions, every time the end gets close, someone will say “one more month is safer.”
Write down the rollback conditions too
The opposite direction matters just as much: under what circumstances do you go back? For example, the new system can't ship for more than a set number of hours in a row, unexplained errors in amounts appear, or key data is lost. Agree on the rollback conditions and who makes the call in advance, so that if it really happens, people don't end up arguing on the spot. Writing rollback conditions in advance has a side benefit: when designing the cutover, everyone deals with those risks up front, so you're less likely to ever need them.
How to run cutover week, day by day
Whether cutover week succeeds depends on everyone knowing what to do each day and who is responsible. Below is the schedule I usually use, with a cutover at the start of the month as the example. Adjust the dates to your situation.
One week before cutover: freeze master data. From this day, stop adding or changing master data: customers, suppliers, item numbers, prices. List anything that's needed and create it all in the new system after cutover. Changing master data while you're moving it is the most common cause of bad opening balances.
Two days before cutover: count and settle opening balances. Do a physical inventory count, reconcile receivables and payables, and produce the opening numbers. Don't skip this. If the opening balances are wrong, every day after is wrong. For how much data to move and how to verify it, see The real cost of ERP data migration.
The day before cutover: import and verify opening balances. After importing the opening numbers into the new system, check at least the total value, total quantity, and a few key customers and items. Fix anything that doesn't match that day. Don't carry differences into cutover day.
Cutover day: switch the old system to read-only. From this day on, all new documents are created only in the new system. The old system stays available for lookups but can no longer be added to or edited. This is the single most important step of the cutover. If the old system can still be edited, someone will keep creating orders in it.
First week after cutover: reconcile every day before close of business. At a fixed time each day, the project lead and each department's point person spend fifteen minutes going over the day's key numbers, listing problems and deciding who handles each one. The point of this daily meeting is to surface problems the same day, not let them pile up by the weekend.
First month-end close: the real acceptance test. Only when the first month-end closes smoothly and the numbers match is the cutover truly successful. At that point, use the shutoff conditions you wrote earlier to decide whether to formally retire the old system.
For the detailed items to check during cutover week, like permissions, print formats and integrations, I've put together 20 items in the ERP go-live checklist. That one is a checklist. This one is a timeline. Use them together.
Three things the owner has to do in cutover week
Most of the work in cutover week is done by the project team, but three things only the owner can do.
First, announce the cutover date and hold it. Once it's announced, don't push it back just because one department says it isn't ready. Delay once and everyone learns it can be delayed again. If there's a genuinely serious problem, follow the rollback conditions instead of postponing indefinitely.
Second, don't schedule anything big that week. If cutover week lands on a major promotion, a big shipment or year-end closing, every small problem gets magnified. Picking a relatively quiet business period to switch does more than any technical preparation.
Third, watch the numbers, not the complaints. The first week will bring plenty of complaints. That's normal, because people are using something they don't know yet. What the owner should watch is whether the daily checks match and whether the problem list is shrinking. Complaints fade as people get familiar. Numbers that don't match are the real warning sign. For what to watch in the three months after launch, read 8 numbers owners should watch three months after ERP go-live.
FAQ
How long should old and new systems run in parallel?
For most companies, I recommend covering one full month-end close, roughly one month, so every major document type goes through one cycle. What matters isn't the length. It's writing the shutoff conditions in advance and stopping when they're met, not extending forever.
Can we skip the parallel run and cut over directly?
Yes, with conditions: the old system's data is simple, the opening balances have been carefully verified, or few people were using the old system anyway. Direct cutover is the cheapest, but there's nothing to compare against if something goes wrong. So the opening count and the daily checks in the first week after cutover need to be even more thorough.
When the numbers don't match during the parallel run, which system wins?
Agree in advance that the new system is the official record and the old one is only for comparison. When a difference shows up, find the cause that day: a setup error in the new system, a missed entry, or an error that was in the old system all along. Very often, when you get to the bottom of it, you find the old system had been calculating something wrong for years.
How long should we keep the old system after cutover?
Keep it read-only for lookups at least until the next annual close is done, for historical records and audits. While it's kept, make sure every account has add and edit permissions turned off, and export and back up any data that needs long-term retention. Then decide whether to shut it off completely.
A parallel run exists to retire the old system, not to keep it
In the end, a parallel run has one purpose: prove, at the lowest cost, that the new system can take over. What to run in parallel, for how long, when to stop, when to roll back. Write those four things down before you start, and cutover week is just following the plan.
If you're planning a go-live and aren't sure which cutover approach fits your company, start with How ERP implementation works and build the cutover plan into your implementation plan.
