What happens to Tuesday's paper if the new system is not ready on Monday night?
That is the real question behind every Print MIS/ERP replacement in a plant that runs on a schedule. Not which system is best. Not what it costs. The presses run tonight whether or not your project is on plan, and the edition does not wait for anybody.
Plan the switch the way this guide describes and here is what you get:
Most guides on replacing a Print MIS/ERP stop at planning. Audit your workflow. Build a team. Clean your data. Set a realistic timeline. All true. All necessary. And none of it tells you what to do on the night itself.
This guide is about that night.
Take your average edition. Add up what one missed edition actually costs you. The copies you cannot sell. The advertising you have to make good. The reprint, if you reprint. The distribution slot you lose. The phone calls the next morning.
Write that number down.
It is not a scare tactic, it is your budget. Every step below costs time, and every step below exists to protect that one number. Once it is on paper, the argument about whether you can afford a proper test week tends to answer itself.
Most projects set a go-live month. Set a go-live edition instead. One specific production, on one specific night.
Choose your lightest week. Stay away from election coverage, campaign supplements, the run-up to Christmas, year-end closing, and any week where one product carries unusual volume. Then build the plan backwards from that night, so every other date in the project becomes a date relative to it.
If your team cannot name the go-live edition, you do not have a cutover plan. You have a wish.
Your old MIS/ERP is not the system you are replacing.
The system you are replacing is your old MIS/ERP plus every spreadsheet, shared document, local database and printed list that grew up around it because it could not do something. Paper reservations in a spreadsheet. The insert calendar somebody keeps by hand. A waste log on a clipboard. The pricing sheet with the real prices that one person updates and nobody else touches.
Walk the plant and count them. Each one is either a requirement for the new system or a habit you are about to break, and both need a decision before go-live rather than after.
The default assumption is that everything has to come across. It does not. Trying is where schedules die.
A rule that works: migrate what you need in order to plan, produce, calculate and invoice from day one. Master data, open orders, current prices and contracts, active materials. History goes into a read-only archive people can still search, not into the new system.
Ten years of closed jobs feel valuable right up to the moment they turn into a three month mapping exercise. If you genuinely need year on year comparison, migrate a defined window, say the last two closed years, and be explicit that anything older lives in the archive.
Migrated dirty data is dirty data with a new address and a longer explanation.
Clean it where it lives now. Customers spelled three different ways. Paper grades that mean the same thing under two codes. Cost centres nobody has used since the last press was installed. Products last ordered in 2019. Price matrices with exceptions that exist only in one person's head.
Deduplicate, standardise the naming, archive what is dead. Do it before the first test load, because cleaning after migration means doing the same work twice, once in each system.
A demo job proves the software works. A real edition proves your data works. Those are very different things.
Take an actual production from last week, one you have complete figures for, and push it end to end through the new system. Planning, plates, press, copy count, mailroom, dispatch, post calculation, invoice. Then reconcile the result against what really happened on the floor.
Where the numbers differ you have found either a data problem or a process somebody changed without telling anybody. Both are far cheaper to find now than in your first live week. Then do it again with an edition that has something awkward in it: a late edition change, a collect production, an insert running on its own schedule.
Full parallel running sounds like insurance. In practice it means asking people who already work nights to do every job twice, and quality drops in both systems at the same time.
Pick the two or three processes where failure is visible to a customer or to the accounts, and run only those twice for a defined number of editions:
Everything else moves clean on the go-live edition. Set the end date for parallel running in advance and hold it. Otherwise it quietly becomes permanent, and you are paying for two systems while trusting neither.
Name the date after which nobody creates a new customer, a new material, a new price or a new contract in the old system. Put it in writing. Put it on the wall.
Without a freeze your migrated master data starts drifting the moment it lands, and you spend go-live week hunting the six records somebody added in between. With a freeze, anything created after that date is entered once, in the new system, by somebody who knows they are doing it.
For the first three productions: one named person per shift who owns the new system, one number to call, and somebody from the supplier reachable at press time rather than during office hours.
Then answer the question everybody assumes already has an answer. What is the fallback?
Decide in advance what going back would actually mean. Which point in the night is the last one where reverting is still possible. Who has the authority to say the word, without calling a meeting. What would have to be re-entered by hand the next morning if it happens.
A fallback nobody has costed is not a fallback. It is a hope.
You will probably never use it. The value is that the decision is already made at 23:40, when nobody should be inventing one.
Go-live is not the finish line.
Take the first full month invoiced from the new system and compare it line by line against the same month handled the old way. Differences fall into three groups: data that did not migrate correctly, a process somebody changed during the project, and things the old system was quietly getting wrong all along.
That third group is usually the biggest. It is also the reason you changed systems in the first place.
Then go back to your list from step 2. If those spreadsheets are still alive after 90 days, the migration is not finished, whatever the project plan says.
Panorama Consulting Group's 2026 ERP Report surveyed 170 organisations between January 2025 and January 2026. Almost a quarter of projects ran over schedule. More than a quarter ran over budget. And the most common reason given for running late was not technical at all. It was organisational: governance, resistance to change, process redesign.
That matches what happens in print. The software is rarely what fails. What fails is the sequencing, the freeze date nobody enforced, and the parallel run that expanded until people stopped trusting either system.
For a single site newspaper or commercial plant, plan on six to twelve months from contract to go-live, with the heaviest load in data preparation. Multi site groups and plants with deep press and mailroom integrations take longer, mostly because of interface testing rather than the MIS/ERP itself.
Not across the board. Run parallel on the processes where failure is irreversible or visible to a customer, typically planning, copy count and one billing cycle. Running everything twice doubles the workload for night staff and usually degrades data quality in both systems at once.
Migrate what you need to operate and calculate from day one, plus a defined window of closed history if you need year on year comparison. Keep the rest in a searchable read-only archive. Full history migration is the single most common cause of a slipped go-live date.
In your lightest production week, away from year-end closing, election coverage, seasonal supplements and holiday schedules. Pick the specific edition rather than the month, and check that your key people are not on holiday that week.
Master data that was never cleaned, a freeze date that was announced but not enforced, and shadow spreadsheets nobody declared until they broke. All three are visible before go-live if you go looking for them.
Yes, and it is the normal outcome when the cutover is planned as its own project rather than as the last week of the implementation. The plants that lose an edition are almost always the ones that treated go-live as a date rather than as a production.
You do not need a consultant to start this. You need one agenda item and about forty minutes.
If the room can answer the first five, you are ready to choose. If it can answer the last three, you are ready to switch.
If it cannot answer either set, you have just found your next two weeks of work, and that is a better outcome than finding it out in go-live week.