MERGE, Part 4: Go Live. Day One is an operating milestone

Part four of five. In Map, we find out what the buyer and the target are actually working with. In Estimate, we put a cost, an owner and a date against the work. In Realise, we agree the target state and turn it into a plan people can run.

Go Live is where that plan becomes the way the combined business works. Not just its technology. Its teams, decisions, customer services, financial controls and the savings the deal was priced on.

A transaction can complete while two businesses remain operationally separate. Sometimes that is deliberate and sensible. Sometimes it means nobody has made the difficult decisions yet. The distinction matters. Go Live is not an instruction to combine everything on the legal completion date. It is the controlled delivery of the changes this particular deal needs, in a sequence the business can absorb.

The outcome: critical milestones delivered and the business transitions. The number: milestones hit against the dates set at Estimate. A milestone counts when the business can use what has been delivered, not simply when a project team marks an activity complete.

1. Go Live is more than Day One

There are usually several go-live moments inside a merger. Legal completion is one. The first morning under new ownership is another. Moving a business onto a new identity platform, combining a support operation, transferring payroll, migrating a product or leaving a transitional service can each have its own cutover.

Those moments do not have to happen together. In fact, forcing them together can create dependencies the team cannot safely manage. A change to email may look small until it breaks customer notifications, application sign-in or the service desk. A finance migration may look self-contained until somebody discovers that order processing depends on the old customer identifiers.

The question is not, “Have we gone live?” It is, “Which part of the business is now working in the agreed way, what evidence shows that, and what remains?”

Some acquisitions need substantial consolidation. Others need the target to retain a distinct product, brand or operating model while selected controls and services change. A carve-out may first need independence from the seller rather than integration into the buyer. Go Live follows that agreed design. More consolidation is not automatically a better result.

2. Protect the business while changing it

The first obligation is continuity. Customers still need their service. Colleagues need access to their tools and to be paid. Suppliers need to know who can authorise an order. Finance needs a reliable view of cash. Security incidents still need an accountable response.

Day One readiness therefore starts with business services, not a list of systems. For each critical service, identify the people, applications, data, suppliers and approvals it depends on. Then test the actual journey.

• Customer support: can a customer reach the right team, can that team see the history, and can it resolve or escalate the issue?

• Order to cash: can an order be accepted, fulfilled, invoiced and reconciled under the arrangements that apply after completion?

• Payroll: are employee records, approvals, funding and processing responsibilities clear, including exceptions?

• Procurement: can people buy what the business needs, with valid supplier records and appropriate authority?

• Finance: can the business report and reconcile, rather than merely open the new finance application?

• Cyber response: who receives an alert, who decides what to isolate, and who communicates if a service goes down?

This is the difference between “the system is available” and “the business can operate”. A successful sign-in is not proof that a colleague can do their job.

The NCSC's business continuity guidance recommends identifying critical services and dependencies, developing feasible workarounds and testing the plans. Its context is disruptive cyber attacks, but the dependency discipline is useful when planning a merger cutover too.

3. Define what must change, what can wait and what must not change

An integration plan needs boundaries. Without them, every useful improvement becomes part of Go Live and the team loses sight of what the deal actually requires.

We would separate the work into three questions:

• What must be true on Day One? The minimum operating arrangements, access, controls, communications and support needed for the business to continue under its new ownership.

• What changes at a later, planned cutover? Changes that need preparation, rehearsal or a quieter business window, such as data migration or a shared platform.

• What should stay as it is for now? A service that is working, a product customers rely on, or a team structure that should not be disturbed before its dependencies are understood.

“Not now” is a decision, not neglect, provided it has an owner, a reason and a review point. Leaving a target on an existing platform temporarily may be the right answer. Leaving it there indefinitely because nobody owns the decision is a different matter.

Each cutover needs a defined scope and acceptance criteria. “Move support” is too loose. “The receiving team can handle the agreed cases, access the required records, meet the agreed service level and escalate exceptions” gives the business something it can check.

4. Run one sequence, not a collection of disconnected projects

Technology, operations, finance, product, HR and legal can each have a credible plan and still create a poor combined result. The problem often sits between their plans.

A team cannot remove a platform before the users and data have moved. A contract cannot be cancelled before the replacement service is accepted. A new organisation chart does not settle who owns a customer incident. An email-domain change cannot be treated separately from identity, security and the systems that send messages.

Go Live needs a shared sequence showing these dependencies. For every milestone, the team should be able to answer:

• What has to be ready before this can start?

• Who owns delivery, and who has authority to accept it?

• Which other teams need to act or stop changing something during the window?

• What happens if this milestone slips?

• Which cost, service or deal assumption does it affect?

The dates set at Estimate remain the reference point. If a dependency changes, we do not quietly replace the original date and present the plan as on time. We record the change, explain the consequence and make the revised decision visible.

This is a practical part of merger synchronisation: getting the teams and their decisions moving together, not just giving them the same project template.

5. Rehearse the cutover and decide when to stop

A cutover plan should be something the team can execute under pressure. It needs named actions, a sequence, time windows, checks, decision points and contacts. “The IT team will migrate the data over the weekend” is not a runbook.

Before the live change, rehearse the important parts in an appropriate environment. Test data mappings, access, interfaces, performance and business transactions. Include the people who will use and support the service, not only the people building it.

Microsoft's migration guidance recommends preparing stakeholders with the schedule, responsibilities and support contacts, and reviewing verification procedures and rollback criteria before migration. That guidance is written for cloud migration, not every merger, but it makes an important distinction: readiness includes the response when the change does not behave as expected.

A go or no-go decision should be based on evidence:

• Have the critical tests passed, and are unresolved issues understood?

• Are the people, suppliers and receiving teams available?

• Are backups or recovery arrangements tested for the relevant failure?

• Can the business continue if the cutover is delayed?

• Who can authorise proceeding, pausing or reverting?

Rollback also needs care. Once new transactions have been written, reverting a system may not restore the business to its previous state. Some changes need forward recovery, transaction reconciliation or a manual workaround instead. The team needs to know which option is feasible and where the point of no easy return sits.

A rehearsed way back is useful. An untested assurance that “we can always roll back” is not.

6. Treat data as an operating responsibility

Copying records is not the same as transferring a business. Data has meaning, ownership, permissions and obligations attached to it.

Before migration, decide which records move, which remain, which can be archived and which should be deleted under the applicable retention arrangements. Check whether the buyer is entitled to receive and use them. In a carve-out, the seller's and target's information may be mixed together, requiring separation rather than a whole-database export.

Then reconcile. A matching record count is helpful, but it does not prove that balances, relationships or permissions are correct. Check the business totals and the journeys that depend on the data. Can finance reconcile opening balances? Can support find the right customer's history? Do the right people, and only the right people, have access?

Identity deserves its own attention. Joiner, mover and leaver arrangements, privileged access, authentication, licences and service accounts all need ownership. An application may work for a test user while failing for a colleague whose access depended on the seller's directory.

The practical output is not “data migrated”. It is accepted data, usable in the receiving service, with known exceptions and a named person responsible for resolving them.

7. Bring the teams together without losing what makes them work

A merger changes more than reporting lines. People may lose authority, familiar colleagues, status or a way of working that made them effective. They may also have sensible concerns about the buyer's tools and decisions. Calling all of that resistance misses useful information.

The target team often holds knowledge that is not in the diligence documents: how a release really happens, which customer needs a careful handover, why a supposedly redundant system is still used, or what breaks when a particular supplier is unavailable.

Go Live needs to retain and transfer that knowledge while the team can still provide it. Identify the critical people, their workload and the tasks that depend on them. Create cover. Give them time to document and teach. Do not make the same person responsible for normal operations, every integration question and a major cutover without changing their capacity.

There is also the Them and Us problem. Two teams can share a platform and still work as separate camps. The visible symptoms are practical: decisions referred back to the old leadership, different release rules, competing priorities and incidents passed across a boundary rather than owned.

Make the new working arrangements specific. Who sets priorities? Who accepts risk? How are changes approved? Which meeting settles a disagreement? How does someone raise a concern without being treated as disloyal?

Where Kolbe is used inside the integration, it helps inform how people approach work and where working styles may collide. It does not replace discussion, technical judgement or evidence of performance. The purpose is to make the combined team work, not to label people.

8. Communication is part of delivery, not an announcement at the end

People need different information at different times. A customer needs to know whether their service, contact or invoice details are changing. A colleague needs to know what they should do on Monday morning. A manager needs to know what has been decided, what remains open and where to take a question.

The CIPD's communication and consultation checklist encourages planning what to communicate and when, and considering where staff input can help shape change. The needs depend on the change; a broadcast is not always a substitute for a conversation.

For each go-live moment, the communication plan should make clear:

• What changes, when, and for whom.

• What is staying the same.

• What the recipient needs to do, if anything.

• Where help is available and who owns it.

• How an unresolved question will be answered.

Do not announce certainty the team does not have. If an issue is open, say what is open, who is resolving it and when the next update will come. That is calmer and more useful than repeated reassurance.

HR and legal need to assess any consultation or employment obligations for the transaction and jurisdictions involved. A communications plan does not, by itself, satisfy those obligations.

9. Make transitional services temporary in practice

In a carve-out, a transitional service agreement may keep the business running while it becomes independent of the seller. That can be sensible. The danger is treating access to the seller's service as evidence that separation is complete.

A TSA needs an operational owner as well as a contract. For each service, specify what is supplied, who uses it, the agreed service level, how problems are escalated, the cost, the exit date and any notice or extension arrangements. The appropriate duration depends on the service and the deal; there is no useful universal timetable.

Build the exit backwards from business acceptance. The replacement has to exist, the data and users have to move, interfaces have to work, and the receiving team has to support it. Contract notice periods and seller availability belong in that same sequence.

A technical migration can finish while the seller still provides an overlooked approval, support function or reporting feed. The exit check is therefore: can the business operate without this service, and has the authorised business owner accepted that position?

If an exit slips, show the financial and operational consequence promptly. An extension can mean additional fees, duplicated running costs or continuing dependence. Those consequences belong alongside the milestone, not in a separate spreadsheet discovered later.

Hutton's video below explores how a single word can derail a carve-out. The wider point is that contract wording has to match what people will actually deliver. For more on separation, see Carve-Out: Where Do You Start? and Why a Target Operating Model Can Save Your Carve-Out.

10. Keep products and customers in the decisions

Where both firms have products, integration is not just a platform decision. It involves customer commitments, roadmaps, support, pricing arrangements and the people responsible for delivering them.

Agree what to keep, combine or retire, and why. Check the effect on existing customers before assuming that moving everyone onto one product is the right answer. A technically successful migration can still leave customers without a feature or workflow they relied on.

Product and technology teams need one view of the sequence. A platform change may require product work first. A product retirement may require contractual notice, customer migration and support capacity. A shared roadmap is only useful when the teams can actually deliver it alongside their existing commitments.

Evidence matters here too. Track whether migrated customers can complete the important journeys, whether service issues are resolved and whether the receiving team can support the product. “Both teams attended the roadmap meeting” is not a customer outcome.

11. Track the savings without counting them before they exist

The deal model may assume that duplicate costs will be removed or that the combined business will perform better. Go Live connects the delivery milestones to those assumptions.

Take a proposed platform consolidation. Moving users is one milestone. Retiring the old service is another. Ending its contract is another. Confirming that the cost has stopped, after allowing for replacement and transition costs, is another. The saving has not landed simply because the migration slide is green.

For each material assumption, keep the original baseline, the agreed target, the implementation cost, the expected timing and the person responsible. Separate recurring reductions from one-off changes, and gross reductions from the net effect. Finance should validate what has actually changed.

An illustrative example, not a client result: a buyer plans to remove a duplicate support tool. The users move, but the old contract cannot end until its notice period expires and an archive is available. Operational delivery has progressed; the recurring cost has not yet stopped. Reporting those as separate facts gives the board a usable picture.

Go Live delivers and checks the changes needed for the savings. Evolve continues the work of consolidation, removing spend and verifying sustained results. The stages overlap; the handover does not erase an unfinished commitment.

12. Give the business a clear decision and support rhythm

During a cutover, normal meeting arrangements may be too slow. The team needs a defined operating rhythm: when status is checked, where issues are recorded, who makes decisions and how urgent problems reach them.

Keep an authoritative record of milestones, dependencies, decisions, issues and acceptance evidence. An email exchange can explain a decision, but it should not be the only place that decision exists. Otherwise the team spends the live window reconstructing what was agreed.

Lens: Merger OS™ provides a place to carry the evidence and the integration record. It does not take accountability away from the people running the work. A named human still owns the decision, the milestone and the judgement about whether the business is ready.

The post-cutover support period, often called hypercare, also needs boundaries. Decide which team receives issues, how they are prioritised, which suppliers remain available and what evidence is required before ordinary support takes over. Its duration should follow the risk and the acceptance criteria, not an arbitrary anniversary of completion.

The NCSC's incident response guidance supports documented contacts, escalation and decision arrangements for cyber incidents. Go Live should connect to those existing arrangements, not create a parallel process that nobody knows how to use.

13. Report what is true, not what looks tidy

A useful Go Live report tells a decision-maker what has changed and what needs their attention. It does not need every task in the plan.

• Milestones: accepted, due and overdue, measured against the dates set at Estimate, with approved changes shown separately.

• Service continuity: critical journeys working, incidents open and workarounds still in use.

• People readiness: receiving teams able to operate, critical knowledge transferred and gaps in cover.

• Financial consequences: transition spend, continuing duplicate costs and savings confirmed by finance.

• Separation: transitional services still active, exits due and dependencies that put them at risk.

• Decisions: what needs approval, who needs to decide and the consequence of waiting.

A green milestone with no acceptance evidence is an assertion. A completed technical task with an unresolved business dependency is incomplete delivery. The aim is not to make the report look harsh; it is to let the right person act while there is still time to change the result.

TIE applies here in practical terms. Truth: an honest verdict, no varnish, no spin. Immediacy: same-day responses while your process is live, not at the readout. Efficacy: the best for the business, not the cheapest or the fastest.

14. Know when Go Live is complete enough to hand over

The end of a cutover window is not automatic acceptance. Nor should an integration team remain indefinitely because nobody defined the finish.

For each service or change, the receiving business owner should accept that it works to the agreed criteria. Support ownership, access, documentation, monitoring, training and supplier arrangements need to be in place. Any outstanding defects must be known, prioritised and owned, with an agreed resolution or accepted limitation.

The handover should also carry the unfinished commercial work: contracts still to end, platforms still to retire, savings still to verify and assumptions that proved wrong. Those become visible work in Evolve, not forgotten items behind a “project closed” message.

Feed the experience back into the method. A dependency discovered at cutover should improve the next Map. A transition cost that Estimate missed should improve the next estimate. A plan that depended too heavily on one person should change how the next deal is resourced.

Before your next Go Live: questions worth asking

• Can we name the critical business journeys that must work, and have we tested them?

• Have we separated legal completion from the operational changes that need their own cutovers?

• Does every milestone have a delivery owner, an acceptance owner, a date and evidence?

• Are data, identity, product and people dependencies in the same sequence?

• Do we know who can pause the change and what recovery is genuinely possible?

• Can the receiving team run and support what is being delivered?

• Does every transitional service have an executable exit plan?

• Are we reporting realised savings separately from expected savings?

• Do colleagues and customers know what changes for them and where to get help?

• Is the unfinished work being handed to Evolve with its original commitments intact?

Go Live is where the merger stops being a plan and becomes a working business. The measure is not the announcement, the number of accounts migrated or the date the project team leaves. It is whether the agreed changes work for the people who have to use them, and whether the milestones behind the deal have actually been delivered.

Next in the series: Evolve, where consolidation continues, spend is removed and what this deal taught improves the next one. Because every deal should be easier than the last.