A planner at a European importer asked a reasonable question in the first week of October. Three of her Asia to North Europe lanes had started arriving eight and nine days early, her exception queue was filling with alerts for cargo that was simply showing up sooner, and she wanted the ETA tolerance widened. The answer came back the same afternoon. The change request sits behind the ERP upgrade, and the next window for anything touching that system is in March. Five months of paging her team about good news.
The network will not wait for your go-live date
That lane shift was not a fluke. Carriers have been putting Asia to Europe services back through the Suez Canal, and the scale of the move is now measurable. In the first two weeks of October, weekly container ship capacity transiting the canal averaged 753,000 TEU, against 1,457,000 TEU in the same weeks of 2023, according to Clarksons Research data published by BIMCO. That is the first time transits have crossed half of pre-crisis levels since the Red Sea diversions began, and the number is still moving.
For an operations team, a routing change of that size is not a headline. It is a month of work. Transit baselines move, in-transit inventory assumptions stop matching reality, demurrage exposure shifts from one port pair to another, and every alert threshold calibrated against a Cape of Good Hope routing starts firing on the wrong things. It is the same work you would do after a permanent reroute: re-measure, re-baseline, re-publish. The difference is that a core systems program sitting on the calendar can make all of it impossible to action.
The freeze is correct. The blindness is not.
Change freezes get blamed for things that are not their fault. A freeze around an ERP upgrade is good discipline. The master data is being migrated, the financial close has to reconcile on both sides of the cutover, and every uncontrolled change is a variable in a test plan that already has too many. Nobody should be editing configuration in that system while it is mid-migration.
The mistake is treating the freeze as though it covers supply chain operations too. Your ERP is a system of record: master data, order books, financial truth. It should be protected. Operations is a system of action: what is late, who owns it, what are we doing about it. That question gets asked a hundred times a day whether or not a cutover is scheduled. Freezing the first does not require blinding the second.
The two only collapse into one problem when the only place your shipment and order data lives is inside the frozen scope. That is a design choice, usually made years earlier and never revisited, and it is the same choice behind the case for connecting ERP, TMS and WMS rather than replacing them. A command center like Orkestra sits in exactly that gap, because it reads from the ERP, TMS, WMS and carrier feeds rather than changing them, and normalizes what comes back into one operational record. Pre-built connectors matter more here than they usually do: Orkestra ships 200+ of them across carriers and core systems, so the operational layer can be stood up without opening a development ticket inside the frozen project.
Map what actually goes dark
Before the freeze starts, run a short inventory with the people who will have to live inside it. Not a risk register. Four questions, answered honestly:
Which operational questions can we still answer on day 30 of the freeze? Where is order 4419, why is it late, who owns it, what did we promise the customer. If any of those answers currently requires a report that only the ERP team can change, write it down.
What breaks silently rather than loudly? A failed integration throws an error. A stale reference table does not. Carrier codes, port codes, calendar tables and tolerance thresholds all drift quietly, and a frozen system cannot be corrected when they do.
Who absorbs the manual work? Freezes do not reduce the work, they relocate it into spreadsheets and inboxes. Name the three people it will land on and ask how many hours a week they can actually give.
What decisions get deferred because the data is not there? This is the expensive one. A deferred expedite decision, a missed demurrage free-time window, a container rolled because nobody saw the booking slip. Price two or three of them. That number is the real cost of the freeze, and it is usually larger than the cost of standing up something alongside it.
Keep the operational record outside the frozen scope
The practical pattern is simple to state and takes a few weeks to do. Pull a read-only extract of orders, shipments and master data out of the ERP before the freeze closes, and keep it refreshing. Connect carrier and forwarder feeds directly rather than through the ERP, because those are external sources and nothing about them belongs in the frozen scope. Hold the result as an event-level record, not a nightly snapshot, so you can still see the sequence of what happened rather than just last night's status.
None of that writes back to the core system, which is the point. It is the same integration discipline described in how to connect your supply chain systems, applied under a constraint that makes it easier rather than harder: during a freeze, read-only is not a compromise, it is the requirement. If you want the mechanics of what connects to what, the integrations side of this is where the work actually sits.
Plan for the cutover weeks, not just the freeze
The freeze is long and predictable. The cutover is short and ugly. For several days around go-live the ERP is in parallel run, partially down, or returning answers that are correct in one instance and stale in the other. Teams plan this carefully for finance and almost never for logistics, which is how a business ends up unable to tell a customer where their order is during the exact week it most needs to look competent.
Decide in advance what the operational source of truth is during those days, and tell everyone. If the answer is the layer sitting above the ERP, it has to be live and trusted well before cutover week, not spun up during it. The Defense Logistics Agency stood up consolidated carrier visibility on Orkestra in four weeks and saw an 83% increase in proof-of-delivery visibility across thousands of shipments a week. Four weeks is the useful number here: it is shorter than most cutover rehearsal cycles, which means the operational layer can be proven before the window opens rather than improvised after it closes.
Do not let the freeze set your architecture permanently
Here is the part worth saying out loud at the steering committee. Whatever you stand up to survive the freeze is going to answer a question your team will keep asking after go-live, which is where operational coordination should live at all. Plenty of organisations discover during a freeze that the layer above their core systems is doing the work they assumed the new ERP would do, and that the honest version of the roadmap is smaller than the one they signed. That is the argument in the 18-month replatform that didn't have to happen, arrived at from the other direction.
Treat the freeze as the cheapest experiment you will ever run on your own architecture. You get months of evidence about what your core systems are genuinely required for, under real operating conditions, at no incremental project cost.
Where to start this week
Find the go-live date and count backwards. If the freeze starts in under eight weeks, run the four-question inventory now and price the deferred decisions, because that number is what buys you the budget. If it has already started, connect the carrier and forwarder feeds first, since those sit outside the frozen scope and give you the fastest return on the two weeks it takes. Either way, scope it as a pilot that proves something rather than a second programme running in parallel with the first. The point is not to work around your ERP. It is to make sure the question "where is my order" keeps having an answer on the days your core systems are busy becoming something else.
