- The first 100 days are set up between signing and close. McKinsey's research on large deals found that 79% of those ahead of their peers at 18 months were still ahead three years later, while only 17% of the laggards turned around.
- Protect trading first. In the same research, 72% of successful mergers held organic growth in year one, against 33% of unsuccessful ones.
- Not everything should be merged. Decide the integration model first, then sort each system into do first, connect, or leave alone.
- Connecting two platforms is not merging them, whether both run Microsoft 365, both run Google Workspace, or one of each. Connection tools are not migration tools.
- Who pays for migration is a deal-term question, and the deal terms limit what you can change and when.
The first 100 days start before close
Day 1 is the day ownership changes, and by then the important decisions have usually been made, or avoided, in the weeks between signing and completion. That window is the last time both sides can plan together without the pressure of a business that is already trading under new owners.
McKinsey's study of a decade of large deals found that the first 12 to 18 months after closing strongly predict long-term results. Of the deals outperforming peers at 18 months, 79% still did three years later, and only 17% of the underperformers turned around. It is research on large transactions, so the numbers will not transfer directly to an ASEAN mid-market deal, but early drift compounds in every size of deal.
One caution. Until completion the two businesses remain legally independent, so planning is not the same as acting on each other's systems. Take advice on what each side can see before close, and use the window to agree the plan, the owners and the sequence.
Pick the integration model before you pick systems
Most integration arguments are one argument in disguise: is the target being absorbed, kept separate, or blended? Settle that in writing, and most system questions answer themselves. Leave it open, and every platform becomes its own debate, decided one meeting at a time.
| Model | Fits when | What it means for IT |
|---|---|---|
| Absorb | The thesis is cost synergy or scale. | One set of platforms and one security standard, reached in stages. |
| Coexist | The target keeps its brand, customers or permissions, or an earn-out depends on it performing as before. | Separate platforms for now, linked for security, reporting and collaboration. |
| Blend | Each side has something the other lacks. | Best system per function, migrated selectively. The most work, and the easiest to let drift. |
Choose the model from the deal thesis, not from which side is larger. A buyer who paid for a capability and then absorbs the team that built it has reduced the value of what was bought.
What to merge first, and what to leave alone
A useful test for any system is whether touching it changes how people work or how customers are served. Things that lower risk without changing daily work can move early. Things that change how people work, or how money is counted, should wait until the business is stable and the model is agreed.
| System | First 100 days | Why |
|---|---|---|
| Security baseline, backups, admin accounts | Do first | Lowers risk and is invisible to most staff. Evidence it before extending any network trust. |
| Contracts and licences | Do first | Change-of-control, renewal and notice dates drive cost and continuity. Consolidate at renewal, not before. |
| Transition services from the seller | Do first | Every service needs an owner and an exit date. |
| Email, calendars and chat | Connect, decide later | People feel the benefit without a migration. Migration is a Day 100 decision. |
| Devices and security monitoring | Connect | Visibility first. Do not re-image devices or change how people work. |
| Network | Connect carefully | A restricted, segmented link once the baseline is evidenced. Never flat-network two estates. |
| Finance and ERP | Leave alone, decide by Day 100 | The costliest and riskiest move, and often what an earn-out is measured on. |
| Customer-facing platforms and line-of-business apps | Leave alone | Protect trading. Change legal notices and branding, not platforms. |
Day 1 to Day 100
Day 1: keep the business running and the door shut. People are paid, customers are served and email flows. Take ownership of access: every admin, service and shared account gets a named owner and a vaulted break-glass route, ideally with the person who holds the keys in the room. Do not connect networks yet, and do not stack system changes on top of the legal ones. Name one integration owner on each side and one escalation route when they disagree.
Days 2 to 30: stabilise and learn. Evidence the security baseline: multi-factor authentication, patching, endpoint visibility and a tested restore. Build the inventory of applications, licences, cloud accounts, domains and vendors, and compare it with what was disclosed in diligence. Read the contracts for change-of-control and renewal dates, and put every date in one calendar. Map the transition services to exit dates. Interview the people who run things before anyone's role changes.
Days 31 to 60: connect without merging. Once ownership has legally transferred, link calendars and chat, bring the target's devices into security monitoring, and open a restricted network link. Take the quick wins only: duplicate tools and licences that can be retired at renewal without disruption. Use a reporting bridge for group finance so consolidation does not need a system migration.
Days 61 to 100: decide, stage and write it down. Make the platform decisions for finance, email and collaboration, and customer systems against the model you agreed on day one, and agree who funds each migration. Plan each as a project with an owner, a rollback and a window that avoids month-end, year-end and peak trading. Start a decommissioning ledger, because running both stacks indefinitely is the most common quiet failure: the second set of systems is paid for long after it has any purpose. End with a published 12-month roadmap and budget.
Same platform, different platform, or a migration
Two businesses on the same platform do not merge themselves. Microsoft 365 and Google Workspace both treat a separate organisation as a separate tenant, with its own domain, identities and sharing model. Connecting them is quick. Merging them is a migration project, and the tools that connect are not the tools that migrate. The table reflects vendor documentation as read in October 2026, so confirm the current position before you commit.
| Situation | Connect now | Migrate later, with care |
|---|---|---|
| Both on Microsoft 365 | A multitenant organisation gives cross-tenant search and Teams. It needs Entra ID P1 in every tenant, and Microsoft says it is not a migration tool. | Mailboxes on hold cannot move, the source mailbox is deleted, signatures and labels stay behind, and each user needs a migration licence. |
| Both on Google Workspace | External sharing of drives and calendars. | Google says a domain transfer does not merge accounts and no single tool merges two accounts across all services, so data moves service by service. |
| One on each | Shared free/busy calendars, mail forwarding or dual delivery, and guest access to files. | Documents convert, sharing links break and chat history stays behind. Our Google Workspace to Microsoft 365 guide covers that path. |
Whichever combination you inherit, wait for legal completion before linking identities, find your legal holds before moving anything, and plan for the human cost of new profiles, broken meeting links and lost chat history landing in the same week. Do not assume the buyer's platform wins either. Choose on licence cost, security controls, the applications that depend on it and the skills available to run it. For many mid-market deals, linking for collaboration and deciding on migration at Day 100 costs less than a rushed move in week three.
Who pays
Settle it in the agreement, not in week six. Deloitte describes the usual default as sellers paying for separation, buyers paying for integration, and migration shared, with frequent exceptions. Whatever the default, your agreement decides, and an unowned line becomes an argument.
| Cost | Includes | Common starting point |
|---|---|---|
| Separation | Carving accounts, licences and shared services out of the seller's estate. | Seller, unless the buyer wants speed. |
| Integration and migration | Security tooling, identity, moving mailboxes and files, migration licences, partner fees. | Buyer, with migration often shared. |
| Double-running | Licences and transition fees while both stacks run. | Whoever controls the exit date. |
| Remediation | Fixing gaps found in diligence, as covered in our technology debt guide. | Price adjustment, escrow, indemnity or buyer budget. |
| People | Retention, knowledge capture and team time. | Buyer, and the line most often forgotten. |
EY's study of large deals put integration costs at 1% to 7% of deal value, and noted that smaller deals can look costlier proportionally because many costs are fixed. Those are large-deal figures, so do not use them as a budget. Do ask for a bottom-up estimate by line, with a contingency, before you sign, and write any seller cooperation, such as admin access and data exports, into the agreement.
Keeping institutional knowledge intact
In a business of this size, much of what keeps IT working lives in a few heads: which account owns the domain, why a task runs at 2am, which vendor contact actually answers the phone. None of it appears in a diligence report, and the risk is rarely malice. It is a well-meaning role change or removed account in week two, before anyone has written the knowledge down.
Capture before you change. Interview the people who run the systems in the first 30 days, while they are in their old roles and the conversation is not about their job. Ask what breaks, what they do on the first of the month and who they ring outside the company when something fails. Agree retention terms for the key people before any change in role is announced, and tell the target's staff early what is and is not changing, because people who think their jobs are at risk stop documenting and start leaving. It works both ways: a joint session where each team explains how it runs things does more for trust than a stream of policy announcements.
While the deal terms are still live
Integration plans are written by operators, but limited by the agreement lawyers wrote. These terms stay live for months or years after close, and each narrows what you can safely change. Read your own agreement with your lawyer, because the wording decides what applies.
| Term | What it constrains | What to do |
|---|---|---|
| Earn-out | Changes to systems, pricing or staffing can move the numbers the payment depends on, or be argued to have. | Agree in writing how metrics are measured and which integration steps are excluded. Leave revenue systems alone during the measurement period. |
| Transition services | Services run on the seller's systems to fixed exit dates, with prices that usually escalate on extension. | Give every service an owner, a replacement and an exit date. |
| Escrow, warranties and indemnities | Notice periods and evidence requirements apply, and changing the environment can make a later claim harder to prove. | Record the baseline before you change anything, and route possible claims through the deal team first. |
| Change of control | Vendor contracts can terminate, re-price or need consent, often with short notice windows. | Check them first and renegotiate while time is on your side. |
| Data protection | The PDPA's business asset transaction exception covers disclosure for the deal. Merging customer or staff datasets afterwards is a separate question. | Take advice before combining datasets. Fines can reach 10% of Singapore turnover for larger organisations. |
Where we come in
If you are buying, the most valuable work happens before signature: an evidenced view of the target's estate, an integration model agreed in writing, and a costed plan that tells you who pays for what. If you are the target's management, the best position is a current inventory, an access list and a plain description of what is fragile, produced before anyone asks.
Either way, we have run this from the operator's side for 15 years. We can help you agree the model, price the migration, line the plan up against your deal terms, or provide the technology leadership for the first 100 days so your own team keeps trading.
Frequently Asked Questions
Should we move everything onto one email and collaboration platform straight away?
Usually not. Link the two environments for collaboration once ownership has legally transferred, and make the consolidation decision at around Day 100. Connection tools are not migration tools: Microsoft states that cross-tenant synchronisation is not one, and Google says no single tool merges two accounts across all services. Native migrations have limits, such as mailboxes on hold being blocked on the Microsoft side and sharing links and Chat history not carrying across between Google and Microsoft. A well-planned migration in month four costs less than a rushed one in week three.
What if one business is on Google Workspace and the other on Microsoft 365?
Keep both running at first and connect them: cross-platform calendar free/busy, forwarding or dual delivery, and guest access to shared files. Choose the target platform at Day 100 on licence cost, security controls, the applications that depend on it and the skills available, not on which business is larger. Cross-platform migrations convert documents, break sharing links and leave chat history behind, so scope them as projects with an owner, a rollback and a quiet window.
Who pays for integration and migration after an acquisition?
It is a deal-term question, so settle it in the agreement. Deloitte describes the usual default as sellers paying separation costs, buyers paying integration costs, and migration costs shared, with frequent exceptions where a buyer funds separation to speed a deal or a seller takes on more of the migration. Agree each bucket in writing: separation, integration, migration, double-running licences and transition fees, remediation of diligence findings, and people costs. Ask for a bottom-up estimate with a contingency before signing.
Can we link the two companies' systems before completion?
Treat it carefully. Until completion the businesses remain legally independent, so planning and sharing information are one thing and acting on each other's systems is another. Take legal advice on what can be shared before close, and on whether the Personal Data Protection Act's business asset transaction exception covers what you intend to disclose. Vendors also design their connection features for use within one organisation. Microsoft says this of cross-tenant synchronisation, so wait until ownership has transferred.
What is a transition services agreement and how does it affect IT?
It is an agreement under which the seller keeps providing services, such as IT, payroll or finance systems, for a fixed period after completion. For IT it means parts of the estate still run on the seller's systems until an exit date. Treat it as a project plan: every service should have an owner, a replacement and an exit date, and steep extension pricing can signal which exits the seller expects you to miss.
Related Guides
- The IT Due Diligence Checklist: What Buyers Actually Look At: The six areas that decide what the first 100 days have to fix.
- Technology Debt as a Deal Risk: How to Quantify It Before You Sign: How findings become price adjustments, escrow or the integration budget.
- Building a Technology Roadmap Without a Full-Time Tech Leader: Turning the first 100 days into a 12-month plan.
- Google Workspace to Microsoft 365 Migration Guide: What migrates cleanly, what does not, and the risks teams underestimate.
- Microsoft 365 Licensing Demystified: The licences behind tenant linking, migration and security monitoring.
Sources and further reading
- In conversation: Four keys to merger integration success, McKinsey & Company, October 2022
- Cross-tenant mailbox migration, Microsoft Learn
- FastTrack cross-tenant migration, Microsoft Learn
- Plan for multitenant organizations in Microsoft 365, Microsoft Learn
- What is cross-tenant synchronization?, Microsoft Learn
- Identity merge and deduplication, Google Workspace Help
- Migrate email from one Google Workspace account to another, open beta, Google Workspace Updates, March 2024
- How to migrate between Google Workspace and Microsoft 365, TechnologyMatch (vendor marketplace article; verify date-sensitive claims against current vendor documentation)
- Google Workspace tenant migration for M&A, CloudFuze (vendor article)
- Estimating, classifying and allocating M&A IT costs, Deloitte Switzerland, December 2021
- Four tips for estimating merger and acquisition integration costs, EY
- Technology M&A 2025: Singapore, Chambers and Partners
- PDPA application to M&A transactions, CNPLaw LLP via Mondaq, September 2019
- Earn-Outs & Post-Closing Integration, Clark Wilson LLP, February 2015 (discussing Whiteside v Celestica International Inc., Ontario Court of Appeal)
- Post-Merger IT Integration Playbook, BD Emerson (practitioner view on sequencing and transition services)