Systems consolidation after acquisition: what to migrate first

The first artifact is an inventory, produced in week one, before any migration decision is made. Every system, its owner, its login, its renewal date, its annual cost and its data-export path. It is dull, it takes a day or two, and it is the single most useful document of the first quarter, because you cannot sequence a migration you have not enumerated and you cannot negotiate a renewal you did not know was coming.

Include the systems nobody thinks of as systems. The spreadsheet that prices jobs. The shared mailbox that is actually the dispatch queue. The information-technology provider whose contract auto-renews. The vertical point solution that runs one part of the business and has no obvious owner. In an owner-operated business a surprising share of the operating stack is either a spreadsheet or a person, and both belong on the map.

While you are enumerating, record where each number on your reporting comes from. Some come from the ledger, some from the field or inventory system, some from the customer database, and some from a human typing. That mapping tells you which reporting is fragile and it also tells you which migrations would silently break a number you rely on.

Migrate what breaks the close; freeze what breaks operations. The accounting ledger is the thing that has to move, because a single-user desktop file on the previous bookkeeper's machine, with commingled personal expenses and a chart of accounts grown by accretion, prevents a reliable monthly close — and in a leveraged acquisition the close has a contractual deadline. Dispatch, inventory and customer systems are the things that must not move, because migrating them stops the business doing the work while you are still learning what the work is.

Almost every first-time acquirer inverts this. The dispatch or field system is the one the team complains about daily, so it feels like the urgent fix, while the accounting file is invisible until the month closes late. Replacing the field system in month two, during peak season, with a team that has just changed owners, is the canonical self-inflicted disaster in this category.

One ordering rule inside the accounting migration matters more than the choice of destination: redesign the chart of accounts first, then convert. Migrating an accretion-grown chart into a new system reproduces the problem in a nicer interface and means doing the work twice. Cleanup of commingled and mis-coded history is a defined project with an end date and is best bought as one.

Two figures about the common desktop-to-cloud path circulate widely and are wrong, and this is a case where publishing the correction is worth more than publishing the advice. The vendor's own documentation states a self-service conversion window of ninety days from company creation, extending to a hundred and eighty with an accountant, and a target file limit of four million rather than the much smaller number repeated across the migration-advice corpus. Check the vendor's current page before you plan around either, but do not plan around the versions in circulation.

Several layers are not migration questions at all in the first quarter — they are continuity obligations. Payroll has exactly one requirement on Day 1, which is that it runs. Do not migrate payroll in the first quarter under any circumstances: a missed or late payroll in month one is trust damage you do not recover, and the theoretical savings from a better provider are trivially outweighed by that risk.

Banking and treasury need action immediately rather than migration: signatory change, new cards, stale automatic debits killed, and a separate account established for debt service. Insurance and benefits were bound to the seller's entity and must be re-papered with an effective time, not just an effective date. Licences and permits frequently do not transfer at all and have to be re-issued against the new entity, which in a licensed trade determines whether the company can legally work next week.

The identity layer is where a small oversight becomes an outage. Domains carry a transfer lock after a registrar change, the business phone number is portable but only through a defined process and losing it loses the business, the mapping listing that generates local leads has its own ownership-transfer procedure, and an email tenant migration is a project rather than a setting. Take control of the domain, the registrar account and the password vault on Day 1; do the migrations later.

Card processing and point-of-sale is a Day-1 revenue dependency and its account transfer has to be confirmed rather than assumed. And through all of this, remember that the closing window is when wire-fraud attempts peak and the operator is the target: any change to payment instructions gets verified by a callback to a number you already held, never a number contained in the message asking for the change.

Three constraints eliminate most candidate dates before you consider anything else. Nothing migrates mid-month, because the close needs a clean boundary. Nothing migrates mid-payroll-period, because reconciling a split period costs more than waiting. And nothing migrates in peak season, because the team has no capacity to absorb a change while running at capacity. In a seasonal business those three constraints frequently leave two viable windows in the year, which is worth knowing before promising anyone a date.

That pushes most real migration into months seven to twelve, which is the correct window for a different reason as well: by then you understand the operation well enough to specify what you actually need, rather than buying what the previous owner's problems suggested. The receivables and payables layers, the human-resources system and the reporting layer all sit comfortably in that window and none of them is urgent before it.

The customer system is the exception that is urgent but is not a migration. Getting the customer list, the pricing history and the named contacts out of the seller's head and into a system belongs in the first thirty days, and which system barely matters. That is owner-dependency work wearing a software hat, and treating it as a selection exercise is how operators spend two months choosing a product while the information they needed walks out of the building.

One discipline for the whole programme: this publication does not do software round-ups, and you should be suspicious of the ones you find. The migration-advice corpus is written almost entirely by vendors, and it is written to sell the destination. The sequencing question — what moves, what freezes, and when — is answerable without naming a winner, and it is the question that actually determines whether the year goes well.