How much of a replatform is integration work?

More than the plan usually allows. Configuring a new system is bounded work with a vendor and a methodology behind it. Rebuilding every connection into and out of the old one is unbounded until somebody produces the inventory, and that inventory routinely turns up connections nobody remembered, particularly scheduled exports, spreadsheet connections and small scripts built by staff. On projects we have seen, the integration workstream is frequently comparable to or larger than the platform configuration, and it is the part most often discovered late.

Should we run the old and new systems in parallel?

For a period, and with a clear definition of what parallel means. Genuine dual entry, where every transaction is processed in both systems, is expensive and exhausting and can only be sustained briefly, but it is the strongest possible proof and it is worth doing for a short window on the highest value flows. A lighter form, where the new system processes live and the old one remains available read only for reference and reconciliation, is the right shape for the following weeks. What does not work is a long parallel period with no comparison discipline, because it simply doubles the workload without producing evidence.

When is the best time to cut over?

At a period boundary, in a trading lull, with your key people available and not on leave. In Australia that usually means avoiding the October to January retail peak and avoiding end of financial year, and it means aligning with a BAS period boundary so the reporting period is not split across two systems with different structures. February to April and mid winter tend to be the practical windows for retail. If the schedule has slipped towards peak, holding for a quarter is almost always cheaper than going live into the busiest fortnight of the year.

How much history should we migrate?

Enough to run the business, not everything that exists. Open transactions must move or be completed in the old system. Reference data must move and should be cleansed on the way. For transactional history, a defined recent period, commonly one to two years, covers the great majority of operational lookups such as returns, warranty and customer service. Everything older is better archived in a readable, queryable form that satisfies your record retention obligations. Migrating a decade of transactions lengthens the project, complicates testing and imports problems the new system will then be blamed for.

What happens to our old product and customer codes?

They usually change, and everything else refers to them: historical orders, carrier consignments, marketing audiences, supplier catalogues, printed labels and your customers’ own purchasing systems. The essential artefact is a cross reference table mapping old identifier to new for every entity that other systems reference, retained permanently rather than discarded after go live. Integrations consult it, and support staff can search on either value. Without it, a straightforward question about an order from before the migration becomes an investigation.

What should our rollback plan actually say?

Three things. First, the objective criteria for proceeding at each stage, expressed as reconciliations that must balance and flows that must be proven rather than as impressions. Second, exactly what rollback involves at each point, including how long it takes and what data is lost. Third, the honest identification of the point of no return, because there usually is one: once you have accepted live orders into the new system and adjusted stock, going back is not a matter of restoring a backup. Knowing where that line sits changes how carefully you approach the steps before it.

Can we keep the old system instead of replacing it?

Sometimes, and it is worth asking seriously before committing. Where the old system does its core job adequately and the actual complaints are about connectivity, reporting or a poor user interface, wrapping it with a modern integration layer can deliver most of the benefit at a fraction of the cost and risk. Where it is genuinely at end of life, unsupported, unable to meet a compliance requirement, or blocking a business model you have decided on, replacement is the right call. We are happy to advise on that question honestly, including when the answer is that no integration work will fix the underlying problem.

For businesses replacing a core system without closing for a week

Replatforming: Changing the Engine While the Car Is Moving

Replacing an ERP, a point of sale or an ecommerce platform is sold as a software decision and delivered as an integration problem. The new system is rarely the hard part. The hard part is that a dozen other systems are wired into the old one, orders are in flight, stock is committed, and the business has to keep trading throughout.

The failures are predictable and they are almost never about the new platform. They are about identifiers that no longer match, open orders nobody decided where to land, a financial cutover placed halfway through a reporting period, and a go live with no defined way back. This page is about the parts of a replatform that the platform vendor is not responsible for.

Book a Cutover Planning Call (03) 9003 0111

Realistic ROI

Every integration

Wired to the old system has to be rebuilt

Counting them honestly is the first task, and the count is usually higher than expected

Identifiers change

And everything downstream keys on them

A cross reference table between old and new is not optional

Period boundaries

Are the right place for a financial cutover

Cutting mid period turns a reconciliation into an archaeology exercise

A defined way back

Is what makes a go live decision possible

Without rollback criteria the decision is made on optimism at midnight

Four Things That Decide Whether a Cutover Goes Cleanly

These four are decided early, cheaply, and almost always too late.

Count the integrations before you count anything else

The old system is connected to more things than anybody remembers: the store, the point of sale, freight, the marketing platform, a bank feed, a reporting tool, three spreadsheets with connections in them, and a script someone wrote in 2019 that emails a supplier every Tuesday. Every one of those is either rebuilt, retired or deliberately left behind, and the ones nobody listed are the ones that fail in week one. Produce the inventory first, with an owner and a decision against each entry.

Identifiers will change and everything keys on them

Customer numbers, product codes, order references and account codes rarely survive a migration unchanged. Every other system, every historical record, every carrier consignment and every marketing audience refers to the old ones. You need a cross reference table mapping old identifier to new, retained permanently and consulted by the integrations, so that a customer service enquiry about last year’s order still resolves and a supplier quoting an old code is understood.

The cutover date is a financial decision

Cutting over at a period boundary, ideally one that aligns with a BAS period and with a natural trading lull, makes the financial reconciliation tractable. Cutting over mid period means the same reporting period is split across two systems with different structures, and every subsequent comparison requires explanation. Australian retail also has a well defined peak from October to January, so a replatform going live in November is a decision that should be made deliberately rather than by schedule slippage.

A go live decision needs a defined way back

Go live is usually decided late at night by tired people who have invested months. Without objective criteria agreed in advance, what should be an evidence based decision becomes an optimistic one. Write the criteria down while everyone is calm: which reconciliations must balance, which flows must be proven, what defect level is acceptable, and what the rollback actually involves at each point. Sometimes rollback is genuinely impossible after a certain step, and that is worth knowing before you take it rather than after.

The Six Parts of a Cutover

Each one is a separate decision with a separate failure mode. Confusing them is how weekends get lost.

Discovery

Integration inventory

Every connection into and out of the system being replaced, including the informal ones: scheduled exports, mailbox rules, spreadsheet connections, reporting tools and anything a staff member built themselves. Each entry gets an owner, a decision to rebuild, retire or defer, and a note of what breaks if it stops. This artefact drives the whole programme and it usually takes a fortnight of asking people what they actually do.

Migrated first

Reference and master data

Customers, products, suppliers, pricing and chart of accounts move first and are reconciled before anything transactional follows. This is where cleansing decisions get made, and the temptation to migrate everything is strong. Duplicates, obsolete lines and dormant accounts are better resolved now than carried forward, since a new system inherits the reputation of the data it launches with.

Permanent

Identifier cross reference

A retained mapping between old and new identifiers for every entity that other systems refer to. Integrations consult it, support staff can search on either value, and historical documents remain resolvable. Businesses that treat this as a throwaway migration artefact discover eighteen months later that they cannot connect a warranty claim to the order that generated it.

Decided per type

Open transactions

Unfulfilled sales orders, open purchase orders, partially received goods, unpaid invoices, credit notes, layby and backorders. Each type needs a decision: complete it in the old system, migrate it, or re enter it. There is no universal answer, and the decision must be made per type with finance and operations in the room, then executed in a sequence that leaves nothing stranded between the two systems.

The weekend

Stock and financial cutover

A freeze window, a physical or system stocktake, opening balances loaded, and reconciliation on both sides before trading resumes. The freeze has to be agreed with sales channels in advance, because a website that keeps accepting orders during a stock freeze creates exactly the mess the freeze existed to prevent. Keep the window as short as the reconciliation genuinely requires and no shorter.

After go live

Parallel period and decommissioning

The old system stays available in a read only capacity while the new one is proven, then is decommissioned deliberately: licences ended, data exported in a usable format, and retention obligations satisfied. Australian tax record keeping requirements generally mean business records must be retained for five years, so decommissioning is an archiving exercise rather than a deletion, and the archive needs to be readable without the original software.

Cutover Decisions and How They Play Out

Task	Traditional	Planned Cutover	Notes
Unknown integrations	Discovered when they break	Inventoried with an owner each	The connections nobody remembers are reliably the ones that fail in the first week.
Changed product codes	Downstream systems silently mismatch	Cross reference consulted by integrations	Retain the mapping permanently, not just for the migration weekend.
Orders placed mid cutover	Land in whichever system was up	Freeze window agreed with channels	A website still taking orders during a stock freeze defeats the freeze entirely.
Open purchase orders	Rekeyed hurriedly or forgotten	Decision made per transaction type	Finance and operations must agree this together, well before the weekend.
Historical data	All of it migrated, slowly	Recent migrated, rest archived readably	Migrating a decade of transactions imports old problems and delays go live.
Go or no go	Decided by fatigue at midnight	Measured against written criteria	Criteria written while calm are the only ones worth having.
Something goes wrong	Improvised recovery	Rollback rehearsed and time boxed	Some steps are genuinely irreversible, and knowing which ones changes the plan.
The old system	Left running indefinitely	Archived, then decommissioned	Record retention obligations are met by a readable archive, not a dormant licence.

Where Replatforming Projects Come Apart

The integration work treated as a line item

Platform selection consumes months of attention while the integration work is estimated in a paragraph. In practice, rebuilding the connections to the store, the point of sale, freight, marketing, banking and reporting is frequently a larger effort than configuring the new system, and it cannot start until the new system’s structures are settled. Scope it as a workstream with its own plan and its own owner, and get the integration inventory produced before the platform contract is signed rather than after.

Migrating everything because deleting feels risky

Ten years of transactions, dormant customers, obsolete products and duplicate records are not made better by moving them. They slow the migration, complicate testing, and give the new system the same reputation for unreliable data that the old one had. Migrate the reference data you need cleaned, the open transactions you must, and a defined period of history. Archive the rest in a readable, queryable form that satisfies your record retention obligations without occupying the live system.

Going live into peak trading

Australian retail volumes rise sharply from October and stay high through January, and a system that is comfortable in August can be overwhelmed in November while the team is still learning it. Freight cut offs, marketplace deadlines and staff availability all tighten at the same time. If the calendar has slipped towards peak, the disciplined decision is to hold until February rather than go live into the worst possible fortnight. That decision is much easier to make in September than in the second week of November.

No agreed reconciliation before trading resumes

Trading should not restart on the assumption that the migration worked. Agree beforehand exactly which reconciliations must balance: stock quantity and value, debtor and creditor balances, open orders by count and value, and a sample of customer records checked end to end. Assign each one an owner and a threshold. This is the difference between finding a problem during a controlled window and finding it three weeks later mixed in with a month of new transactions.

The old system switched off too quickly

Questions arrive for months: what was this customer’s old balance, which batch was in that order, why does this figure differ from last year. Keep the old system available in a read only capacity for a defined period, then decommission it deliberately with the data exported into a format that can be read without the original application. Australian record keeping obligations generally require business records to be retained for five years, and a backup that only restores into software you no longer licence is not a usable archive.

Nobody owns the connections after go live

New integrations built in a project have no operational owner unless one is assigned, and the project team disbands. Three months later a vendor changes an interface, a flow stops, and nobody is watching. Establish monitoring, alerting and a named owner for every rebuilt integration as part of the go live checklist rather than as a follow up phase, because the follow up phase is the first thing cut when the project runs late.

How Yes AI Approaches a Replatform

The integration inventory produced first

We find every connection into and out of the system being replaced, including the informal ones people forget they built, and give each a rebuild, retire or defer decision with an owner. This is the artefact that makes the rest of the plan realistic.

Identifier mapping treated as permanent

A retained cross reference between old and new identifiers, consulted by the integrations and searchable by your support team, so historical records stay resolvable long after the migration weekend is forgotten.

Rebuilt on a layer that outlives the project

New connections run on a managed cloud automation layer we operate, with monitoring, alerting and a named owner from day one, so the flows do not quietly become orphaned once the project team disbands.

Go live criteria written while everyone is calm

Which reconciliations must balance, which flows must be proven, what defect level is tolerable, what rollback involves at each step, and where the point of no return actually is. Agreed weeks in advance, not debated at midnight.

From Platform Decision to a Cutover That Holds

Five steps. The inventory and the plan are worth producing before the platform contract is signed.

Inventory every connection

Formal integrations, scheduled exports, spreadsheet connections, mailbox rules and staff built scripts, each with an owner, a decision and a note of what breaks if it stops.

Decide data scope and identifiers

What reference data migrates and how it is cleansed, how much history moves and what is archived, and how old identifiers map to new ones in a cross reference that is retained permanently.

Plan the cutover sequence

Freeze window agreed with every sales channel, a decision per open transaction type, the order of operations for the weekend, and the reconciliations that must balance before trading resumes.

Rebuild and run in parallel

Integrations rebuilt against the new system and exercised on real data, with a parallel period where both systems process the same transactions and results are compared rather than assumed.

Cut over, reconcile, then decommission

Execute the rehearsed sequence, reconcile against the agreed criteria, watch closely for a fortnight with monitoring and named owners, then archive and decommission the old system deliberately.

FAQ

Replatform Without Losing a Trading Week

Book a call. We inventory every connection, plan the cutover sequence and write the go live criteria, and give you a priced plan. The integration inventory is yours either way.