Algeria AgencyModernisation
The cutover: running the old and the new at the same time
Replacing a system does not happen over a weekend. It happens across a period when both run, and that period has to be designed.
In every system replacement there is a moment when the old one still works and the new one already does. That moment is not an organisational failure: it is the only known way to change tools without stopping the business. It lasts weeks, it costs duplicated work, and it is nearly always improvised.
It is also where migrations fail. Not at the data load, which is technical and can be tested, but some weeks later: two systems drift slowly apart, nobody knows which one is authoritative any more, and the business ends up returning to the old one because that is where the figures are right.
This article describes that period and how to get through it: what actually has to be done twice, which way entry should flow, how to check the two agree, and how the old system is finally stopped. The companion article covers the decision to replace; none of it is repeated here.
It carries no chart, and this time that is not a refusal: nothing here is decided on a number. It is an article about procedure, and the length of a cutover depends on your trade rather than on an average somebody could publish.
A cutover is a period, not a date
In almost every conversation, going live is a date: we start on the first of the month. That sentence describes what is written in the contract rather than what happens in the business. What happens is a period during which the old system keeps carrying the real work and the new one learns to carry it.
Treating the cutover as a date produces one irreversible decision taken on a Sunday evening, whose only fallback is putting everything back. Treating it as a period produces a run of small reversible decisions, each of which can be undone without undoing the others.
The length depends on your cycle rather than on the size of the software, and that is what plans get wrong. A business invoicing monthly has to watch a full month-end pass through the new system before it can judge; a seasonal business has to watch a season. What decides is the span after which every case in your trade has occurred at least once.
The consequence is that a cutover is planned in events to observe rather than in weeks of work. Until the first correct month-end is a deadline; three weeks is a wish, because it is entirely possible that nothing interesting happens for three weeks.
What has to be true before starting
There is a short list of conditions without which the parallel period only installs disorder faster. They are checked beforehand, and one missing is enough to postpone.
The data load has to be repeatable. Not successful once: repeatable, meaning it can be run again and give the same result. During the parallel period the old system keeps receiving data, and you will need to reload several times. A migration done by hand once is a migration that will have to be redone by hand.
You also need somebody, named, who decides. During this period the two systems will contradict each other on real cases, and the question of which is right will come up several times a week. Without a designated person, every case becomes a discussion, and discussions accumulate faster than they resolve.
Finally, the old system has to stay capable of running alone until the end of the period. That sounds obvious and it is the first compromise people make: something small is switched off in the old one because we are leaving anyway, and the fallback in section seven quietly stops existing.
Running both: what actually gets doubled
Running two systems does not mean doing everything twice. That is the misunderstanding that makes the period unbearable and gets it abandoned after ten days: teams key everything twice, tire, and go back to the old system.
What has to be doubled is the input: whatever newly enters the business during the period — orders, invoices, movements. What must not be doubled is the output: documents sent, payments, messages to customers. One system prints and sends, and it is the authoritative one that day.
That distinction is what makes the period bearable, because it divides the extra work by two or three. It also avoids the most embarrassing class of incident: the customer receiving the same invoice twice, one from each system, with two different numbers.
It has a consequence worth writing on the board: throughout the period there is, at every moment, one authoritative system, and everybody knows which. It is not necessarily the same one from start to finish — the whole point is that it changes — but it must never be ambiguous, and the change is decided rather than noticed.
One direction: where you key, where you read
The simplest way to keep two systems consistent is to let only one receive human entry, and to move data one way to the other. Two systems keyed on both sides drift apart within days, whatever the discipline of the teams.
The natural direction at first is old to new: people carry on working as usual, and the new system receives a copy. That asks nothing of the teams, which is precisely its value — the period starts with no extra effort and no risk.
The reversal, when it comes, is the most important event of the whole cutover, and it has to be announced rather than gradual. From this day, entry happens in the new system and the old receives the copy. A reversal decided department by department produces a period where both directions coexist, which is the one configuration guaranteed to produce wrong data on both sides.
The copy in the reverse direction is worth keeping for a while after the reversal, even once nobody reads the old system. It is not there for working; it is there so the fallback stays real, and it costs little while the mechanism already exists.
Reconciling: three checks are enough
Comparing two systems line by line is a project in itself and nobody sustains it beyond a week. Three checks repeated weekly are enough to catch everything that matters, and they fit on one sheet.
The count: how many objects of each type exist on either side — customers, this month orders, invoices issued. A difference in count is the easiest to see and the most revealing, because it points at a whole category not coming through rather than at one value drifting.
The total: the sum of amounts over the same period. Two systems can hold the same number of invoices and different totals, which indicates a diverging calculation rule — a tax, a rounding, a discount — rather than a transfer problem. It is the check that finds rule differences rather than missing data.
The extremes: the largest and smallest object of the period, looked at by hand on both sides. It sounds artisanal and it is the most effective of the three, because migration defects nearly always lodge in edge cases — the zero-value order, the one with fifty lines, the one cancelled and then reinstated.
The data the old system does not hold
Part of what the business knows is written nowhere in the system you are replacing. It is in people heads, in a notebook, in a file name, or in a convention everybody knows without having written it down.
The frequent cases are always the same: customers with a particular arrangement, items not to be sold to certain buyers, the terms granted to a few. None of that has a field in the old software, so none of it gets migrated — and the new system is judged poor because it does not know what nobody told it.
The parallel period is the best moment to collect them, and that is its second use after verification. Every time somebody corrects by hand something the new system proposed, they have just named an unwritten rule. Those corrections are worth noting as they occur, on the same sheet as the checks.
By the end of the period, that list is the real deliverable of the migration, more so than the data. It holds what the business knew without knowing it did, and it is the first time that exists in a form which survives somebody leaving.
Training on the new while the old still runs
Training done before the cutover is forgotten, because it covers actions nobody will perform for several weeks. Training done after the cutover arrives too late, at the moment the team is working under pressure on a tool it does not know.
The parallel period is the only window where people can learn on real cases without consequence, since the old system still carries responsibility. It is a benefit plans never count, and it justifies part of the duration on its own.
The format that works is not a session but a habit: every person does, in the new system, every day, the work they have just done in the old one. Half an hour a day for three weeks teaches more than a day of training, because the cases encountered are their own.
It has to be accepted that this produces questions whose answer is that the new system does not do it that way. Each is either an unwritten rule from section five, or a change to request, or a habit the business can drop — and sorting them during the period costs incomparably less than sorting them afterwards.
The fallback, and the date after which it stops existing
A fallback plan is not an intention to go back; it is a written procedure saying who decides, on what criterion, in what time, and what happens to the data keyed meanwhile. That last part is the forgotten one and the only hard one.
The criterion must be written beforehand, when nobody is under pressure, and it must be observable rather than an impression. If the month-end cannot be produced in the new system before the fifth is a criterion; if it goes badly is not, because in the middle of it everything goes badly.
You also have to say when the plan stops existing. Going back stays possible while the old system has remained able to run alone; past a certain point — a month of entry only in the new one, a change of organisation — returning costs more than carrying on, and pretending otherwise is more dangerous than admitting it.
That date is decided and announced. It is what separates a cutover from a drift: after that day the business stops asking whether it is going back, and the energy that went into the question goes into correcting the new system.
The days not to choose
Choosing the reversal date is a calendar decision more than a technical one, and a few dates are bad for reasons having nothing to do with the software.
A month-end is the worst moment, and it is the one people choose naturally because it looks tidy. It is when the team is already busy closing, when volumes are high, and when a mistake shows immediately on documents going out. The start of a month, just after a close completed in the old system, offers the quietest stretch and a clean comparison point.
The eve of a holiday period is the second trap: the cutover happens, then the people who can answer are away for two weeks, and the remaining team develops workarounds that have to be undone later. A busy season is the third, for obvious reasons that are nonetheless not always respected.
The simple rule: cut over when you can afford to slow down a little, and when the people who know the trade are present. A system going live in a quiet period is judged on its qualities; the same system going live during a peak is judged on the peak.
Stopping the old one: freeze, archive, unplug
Stopping the old system is not one event but three, separated in time, and confusing them is what leaves zombie systems powered on for years in businesses that did in fact migrate.
Freeze first: nobody keys into the old system any more, it stays readable. It is the only one of the three that is decided, and it has to be announced on a specific date rather than happen through neglect. A system a few people keep feeding to be on the safe side is a system that is not frozen, and the business then has two truths.
Archive next: produce a copy of the data in a form readable without the old software — files, not a system backup. The difference is everything: a backup requires rebuilding the machine and the licence to be read, which nobody will know how to do in five years. A readable export opens with anything.
Unplug last, once the archive has been checked by opening it. That final step frees a licence, a machine, sometimes a maintenance contract, and it is the only one producing a visible saving. It is also the one endlessly postponed, which explains how many businesses still pay for software they no longer use.
What becomes of the old system afterwards
There is nearly always a reason to consult the old system: a question about last year, an audit, a customer returning with an old document. Planning for that avoids keeping a whole system powered on for a need arising four times a year.
The right form depends on the frequency, and it is decided by looking at it honestly. If consultation is rare, the archived export from the previous section is enough, filed where somebody will find it. If it is regular, bringing the history into the new system read-only beats maintaining two tools.
What must not happen is keeping the old system available just in case without deciding its status. It starts receiving entries again, quietly, from one or two people who prefer it, and two years later the business has two live systems and a migration that never ended.
How long to keep it is not decided by feel: it comes from your accounting and contractual obligations, which are nearly always longer than people assume. It is the only parameter on this page coming from outside your organisation, and it deserves a question to your accountant rather than an estimate.
What we do, and what we refuse
Our share is the mechanics of the period: the repeatable load rather than one that succeeded once, the one-way copy and its announced reversal, the sheet of three weekly checks, collecting unwritten rules as they surface, and an archive export readable without the old software. Modest tools, and they are what separates a cutover from a drift.
We refuse to promise a duration. It does not depend on the size of the software but on your cycle: the number of weeks after which every case in your trade has occurred at least once. A supplier announcing three weeks without knowing your month-end or your season is announcing a number chosen to reassure.
We also refuse to run a cutover with no written fallback, including when the client thinks it pointless and it would save us time. The fallback is almost never used; what it always does is oblige everybody to write down in advance the criterion that would say this is going badly, and that conversation has value even when no fallback happens.
Finally, two things on this page happen without us and decide much of the outcome: naming the person who settles it when the two systems disagree, and choosing a reversal date at the start of a month, outside holidays and outside the busy season. Both are free, both can be decided this week, and no tool substitutes for either.
Frequently asked questions
How long should both systems run together?
Long enough for every case in your trade to occur at least once, which depends on your cycle rather than on the size of the software. A business invoicing monthly has to watch a full close pass through; a seasonal business has to watch its season. Until the first correct month-end is a deadline; three weeks is a wish, because nothing interesting may happen in three weeks.
Does everything really have to be keyed twice?
No, and that misunderstanding is what gets the period abandoned after ten days. Input is doubled — whatever newly enters the business — and output never is: one system prints, sends and pays, and it is the authoritative one that day. This divides the extra work and avoids a customer receiving two invoices with two numbers.
How do you check the two systems agree?
Three checks a week are enough. The count of objects of each type, which finds whole categories not coming through. The total of amounts over the period, which finds diverging calculation rules rather than missing data. And the extremes — the largest and smallest object — looked at by hand, because migration defects nearly always lodge in edge cases.
When should entry move to the new system?
On an announced date, never gradually department by department: two copy directions coexisting produce wrong data on both sides. Choose the start of a month, just after a close completed in the old system, outside holidays and outside the busy season. A month-end is the worst moment and it is the one people choose naturally because it looks tidy.
What happens to the old system once the migration is done?
Three steps separated in time: freeze — nobody keys into it, it stays readable — then archive as files readable without the original software, then unplug once the archive has been opened and checked. A system backup is not enough: it requires rebuilding the machine and the licence, which nobody will know how to do in five years.
What use is a fallback plan that is almost never used?
It obliges everybody to write down in advance, with no pressure, the observable criterion that would say this is going badly — if the close cannot be produced before the fifth, rather than if it goes badly. That conversation has value even when no fallback happens. You also have to date its end: past a point, going back costs more than carrying on.
Where we come in
Naming today the person who will decide when the two systems contradict each other settles a large part of the outcome, and costs nothing.
- We make the migration replayable rather than successful once, which is not the same.
- We write the fallback plan before the switch, including when you think it pointless.
- We place it early in a month, immediately after a period close.
No duration will be promised: it depends on your cycle rather than the software’s size, and a date announced early makes you switch at the wrong moment.
Read next
Replacing a system that still works
Four reasons justify replacing an old application. Outside those four, keeping it is almost always the right call — and nobody has an interest in telling you so.Taking back a system nobody answers for: what can be recovered, what has to be rebuilt
Your site runs, your software runs, and whoever built them has stopped replying. A great deal of the answer is public and free.After version one: what evolving custom software really costs
Custom software is not delivered, it is put into service. Everything that matters afterwards turns on how you ask for a change.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.