How to Integrate Two Companies' IT Systems After an Acquisition: the Order, and What Goes Wrong

The deal is signed and the lawyers go home. What remains is two sets of logins, two accounting systems, two customer databases and a savings figure somebody promised the board. Here is the order that holds, the choice to make for each system, and what two public failures show about the rest.

IN SHORT

The short answer

Integrate in this order: first take control of identity, access and monitoring in both companies; then keep money and customer data correct; change what customers see last. For each system decide separately whether to keep it apart, connect it, absorb it into one or replace both, and decide from how the business earns, not from which stack the buyer already owns. The plan starts before signing, because the most expensive failures on record began with a date set before anyone had read the systems.

Post-merger IT integration runs on three clocks at once: Day 1, when nothing may break; the first 100 days, when you learn what you bought and choose; and a consolidation that takes years in a large company. Marriott kept Starwood's systems apart, and an intruder already inside them stayed for two more years. TSB moved five million customers onto a new platform in one weekend, and the platform was not ready. One buyer left the systems separate, the other pushed them together, and both ended up with regulators, so the lesson cannot be "always do the one or the other".

We have not published a case of a full post-acquisition integration, and we will not suggest otherwise. What we can show is the same kind of work done outside a deal: connecting CRMs and warehouses, taking over systems from a previous contractor, upgrading old stacks, moving sites off accounts we did not control. Those projects are linked through the text, each labelled for what it was. The deal side comes from Valeriya Chumachenko, who leads our technical due diligence reviews and has more than ten years in technology M&A.

This is also harder than a guide can make it look. A real integration takes people with long M&A experience, sometimes licensed, and analysts who understand someone else's code from top to bottom, and the teams are sometimes large. It is not free, fast or easy. If your question concerns only the website, Valeriya's What Happens to the Website After an Acquisition? covers it; here we deal with everything behind it.

TWO CASES

Two failures on the public record

Marriott announced the purchase of Starwood for $12.2 billion in November 2015 and closed in September 2016. According to the FTC complaint, it spent the ten months in between reviewing Starwood's security, then began a two-year process of bringing some Starwood systems into its own network. Intruders had been in the Starwood network since July 2014. They stayed until September 2018, with malware in over 480 systems across 58 locations, and Marriott estimated 339 million guest records affected. The UK regulator's penalty notice of October 2020 set a fine of £18.4 million, for the months after GDPR took effect only. Under the FTC order, finalized in December 2024, the companies certify compliance annually for 20 years.

TSB is the opposite shape. Banco Sabadell bid £1.7 billion for the UK bank in March 2015, and its offer document promised about £160 million a year in IT savings from moving TSB onto Sabadell's own platform. Over the weekend of April 20 to 22, 2018, about five million customers moved. The Slaughter and May report, commissioned by TSB's board, describes internet and mobile banking as "unstable and almost unusable" in the days that followed. The FCA's final notice records that TSB did not return to normal until December 10, 2018, received 225,492 complaints and paid £32.7 million in redress. The FCA and the PRA together fined it £48.65 million in December 2022.

Two cautions. TSB did not accept the Slaughter and May findings in a number of key respects, as the FCA notes. And both companies are far larger than most readers of this article; we use them because the documents are public and the mechanisms repeat at any size.

BEFORE SIGNING

Integration starts before the signature

By July 1, 2015, the day after its offer went unconditional, Sabadell had picked Sunday, November 5, 2017 as the go-live date. Slaughter and May notes that the expectation of finishing by the end of 2017 was set "without detailed knowledge of TSB's requirements", and that the pattern of setting a desired end date and then building a plan to fit it held for the rest of the programme.

A synergy figure in a bid is a hypothesis about systems nobody on the buyer's side has yet opened. It has to be tested by the people who will carry it out, while the buyer can still change the price or the terms.

There is a legal limit on how far you can go. Until closing, the two companies remain independent businesses. The FTC's guidance on pre-merger information exchange warns that sharing competitively sensitive data can contribute to unlawful gun jumping, and recommends third-party consultants and clean teams, small vetted groups who see what the business people may not and report only blinded results. You may plan together and you may not run anything together; where that line falls is a question for your lawyer. Access can also be thin for ordinary reasons: Marriott told the UK regulator it could only carry out limited due diligence on Starwood's data systems.

So due diligence should end with a handover, not a report in a drawer. How to run the review is covered in How to Audit a Website or Digital Product Before You Buy It and What Building the Systems Teaches You About Buying Them. The integration team should receive this from it:

A synergy figure is a hypothesis about systems nobody has opened.

THREE HORIZONS

Day 1, 100 days, the long road

Day 1 has one goal: nothing a customer or an employee relies on breaks. Invoices go out, payroll runs, orders ship, support answers. The buyer also takes the keys on that day: who holds admin rights, who may change DNS, who gets the call at 3 a.m. Big visible changes wait, and a freeze on risky releases around closing costs little.

The first 100 days are for learning and deciding. By the end you want a full inventory, a security baseline in both companies, a written choice for each system with its reasoning, and an exit plan for anything the seller still runs. The closest thing we do outside deals is the Project Takeover audit, for a system whose previous team has gone: collect access, check the code, the servers and the integrations, write down what we found, and only then decide whether to extend or replace. When we upgrade old systems, the surprises are the kind no document lists: code nobody remembered, settings that lived only on the old server, a scheduled task running from a forgotten folder.

The long consolidation is where the savings live, and its length is usually underestimated. Marriott planned 18 months for the network integration, and the relevant Starwood systems went off about 27 months after closing. TSB's programme ran from 2015 to April 2018, and to December before service was back to normal. Your company is probably smaller, but each of those plans looked reasonable to serious people on the day it was written.

THE TSA

The seller's systems, on a meter

A transition service agreement, or TSA, comes into play when you buy a part of a group. The unit runs on the seller's ERP, network and identity directory and cannot leave them on the day of closing, so the seller keeps providing those services for a fee and a limited time. A standalone company does not need one, although a small version is common: a paid handover with the founder or the outgoing developer.

Published durations vary. BDO India, citing Gartner in October 2026, puts a typical TSA at 17 months; Deloitte in Switzerland wrote in 2021 that teams often assume 8 to 12 months or more for the whole IT function. Three things tend to go wrong:

• The license does not allow it. Software the seller licensed for internal use may not cover serving a business it no longer owns. Mayer Brown notes that a large carve-out can involve hundreds of such consents, so the agreement should say who obtains and pays for them.
• The scope covers running but not leaving. L.E.K. Consulting separates continuation services from transition assistance, the one-time work of migrating data and transferring knowledge.
• The extension happens by default, because neither side tracked progress against the exit, usually at a higher price.

TSB shows what a rising meter does to a plan. Its agreements with its former parent, Lloyds, carried a core charge of about £92 million a year, set to rise to about £187 million from 2017. Sabadell's Group COO told the reviewers that about £130 million of the promised £160 million saving came from leaving that platform and avoiding the rise. So every month of delay had a price, and the pressure pointed the same way as the date.

Write the TSA as an exit plan from the start. For each service list the owner on both sides, the price, the exit date, the price after that date, and what happens to your data at the end. Include knowledge transfer, and run the exit once before you need it.

FOUR CHOICES

Keep, connect, absorb, replace

There are four honest options for each system, and they rarely all come out the same way in one deal.

The trap is the phrase "we already have a platform for that". Sabadell did have one, and according to Slaughter and May it had integrated twelve banks onto it. But the UK programme was, in the report's words, a migration onto a platform that was substantially new, with over 70 third-party suppliers, and TSB did not consider how far the earlier experience applied. Owning a stack tells you what is cheap to reuse. It does not tell you whether the acquired business fits inside it.

So start with four questions about the business. Which systems hold what makes the acquired company worth buying? Who feels each system directly: customers, staff or a regulator? Does the reason for the deal require shared data here, or only a shared report at month end? And what does a year of running both really cost, against what it costs to move?

These are the projects behind each choice. None was an acquisition; each shows the decision in its plain form.

Connect. For an e-commerce client running Salesforce for sales and a separate warehouse system, we built a custom layer that synced orders in both directions; neither system was broken, so neither was replaced. Our Honda Ukraine platform connects to Honda's internal CRM and inventory systems; launched in 2019, it is still in use, and our team maintains it. On FIAT, the job was for inventory and service booking to keep working when the dealership's CRM pushes an update. How to build such a link is in How to Connect CRM, Website, Warehouse and Accounting So the Data Stays Right.

Keep and upgrade. The Trichocosmetics store sat on PHP 5.6. We moved it to OpenCart 3.0.5.1 and PHP 8.4 and updated its modules and integrations instead of rebuilding it. Inherited systems deserve the same look before anyone writes them off; the test is in An AI Project Stuck on a Legacy System?

Absorb into something standard. A professional services client was sure it needed a custom CRM. We mapped its three-stage sales process and recommended a configured HubSpot: two weeks of setup in place of months of development.

Replace. The LavShash store had been built on Magento by a previous contractor. We started from the business logic, how prices form for each region and delivery for each city, and rebuilt it on Laravel around those rules; in the first year the client saved about $17,000 compared with running the Magento store. The client's plans later changed and the project is on hold, as the case page tells. Another client's large system on PHP 5.3 is getting a full rebuild, because an upgrade would have carried every old workaround along.

For common systems, here is where we would start the discussion:

THE ORDER

Identity first, the front last

Whatever you choose for each system, the work runs in roughly this order, because each layer protects the next:

1. Identity and access. List every admin account, shared password, API key and contractor login in both companies. Remove what nobody can explain, rotate keys, turn on multi-factor sign-in. Move domains, repositories and cloud accounts to the company's name.
2. Visibility. Logs from critical systems in one place, alerts to a person who answers, and a restore test of the backups, since an untested backup is a promise nobody has checked.
3. Money. Billing, payments, accounting and payroll must be right every day, so they change late and carefully, with a daily comparison of old against new.
4. Customer data. Decide which system owns each record, then merge. It comes after money because a duplicate customer is an annoyance and a wrong invoice is a dispute.
5. Operations. Warehouse, logistics, internal tools, connected one at a time.
6. The visible front. Website, apps, brand. It comes last although a CEO wants it first, because a redesign on top of systems in motion gets done twice. A site move has its own traps, set out in The Website Migration Checklist Most Agencies Skip.

We have lived the first step without any deal. Some of our own websites sat on accounts belonging to a former partner company: legally ours, yet every server change depended on an account we did not control. Moving them took an inventory, backups, the migration, redirects and removing copies that should no longer exist. The wider pattern is in Most Companies Don't Own Their Website.

Ownership of the code has to be settled in this same step, before systems are taken over and merged, because developers on both sides may hold rights nobody checked. Look at an IP assignment agreement with a lawyer, who drafts such papers. When we packaged our own business as an experiment, the most important part was documents with all our developers confirming the code is ours.

The steps overlap, and a regulated business may have to reorder them. The principle is that a mistake at the top exposes everything, while a mistake at the bottom is visible and repairable.

A wrong logo gets fixed on Monday. A wrong invoice gets a lawyer.

INHERITED RISK

Assume something is already inside

The part of the Marriott notice most worth reading concerns a system on its way out. Marriott argued that the Starwood system was due to be retired, so heavier measures were not needed. Decommissioning had been intended for the first quarter of 2018 and slipped to the end of that year. The regulator answered that a planned shutdown may affect which measures are reasonable, but "does not remove the basic obligation" to secure the data while it is in use.

A legacy system stays your responsibility for as long as it runs. The ICO named four principal failures: too little monitoring of privileged accounts, too little monitoring of databases, weak control of critical systems and gaps in encryption. Marriott's post-acquisition improvements, it found, did not catch "relevant, easily detectable" deficiencies. Contract protections work between buyer and seller. As Simmons & Simmons observed, due diligence and warranties did not spare Marriott the fine.

For a buyer this leads to practical steps in the first weeks:

• Assume the target may already be compromised, and order a check for exactly that. The security review in due diligence looks at practices; this one looks for traces of someone inside.
• Keep networks apart until that check is done. Marriott's separation helped here: the ICO records that the attack did not reach the wider Marriott network.
• Put monitoring on old systems at once, however soon they are due to go, with a retirement date and an owner for that date.
• Keep an incident plan that names people across both companies, and practise it. TSB's playbooks, the FCA notes, supported only the first 48 hours.

The common ways in are less exotic than people expect; we go through them in How Do Business Websites Get Hacked.

DATA AND CONSENT

Moving records, keeping promises

One line in the TSB report deserves more attention: "the migration of customer records proceeded as planned". The data moved correctly and the bank still failed, because the platform and the people running it were not ready for full load.

Performance testing ran on one data centre of two, so a configuration problem between them could not show up. Test targets were lowered after tests failed, and the summary did not make that clear. The board heard of "around 800" open defects when the real number was at least two and a half times that. After go-live, the FCA adds, TSB could not roll back to the old platform. The report also says a single-event migration is the fastest, cheapest and least complex route, and would not necessarily have been wrong with the right safeguards. So choose it knowingly. In any migration we would insist on the following:

• Rehearse on a closed copy. We do upgrade work on a temporary copy closed to the outside, with anonymized data and no real client records. Repeat the whole run there until it finishes on time.
• Test at peak load on the real configuration, and report any change of target in writing to whoever decides on go-live.
• Reconcile. Counts and totals, old against new, with a person who signs for the difference; our integrations article explains the nightly version.
• Lose nothing in flight. On our own site every lead is written to a log before the email is sent, so a mail failure cannot lose it.
• Know your way back. If there is none, tell the board so and line up extra support in advance.

Then comes the question of whether you may do it at all, because a privacy promise travels with the data. When Facebook bought WhatsApp, the FTC wrote to both companies that WhatsApp must keep honoring its promises regardless of the acquisition, and that they needed affirmative consent before materially changing how they used data already collected. That is one letter about one deal, but the logic travels: read the privacy policy the customer agreed to, and ask whether your plan fits it. Mailing the acquired list about your products, or feeding it into your models, is what your lawyer needs to see. US state privacy laws and GDPR for European customers add their own rules. And leave behind what you do not need: the FTC order requires Marriott to keep personal data only as long as reasonably necessary.

KEY PEOPLE

The knowledge that can resign

Deals change people's jobs at the moment you need their memory. The best data we found is a study by J. Daniel Kim, reported by MIT Sloan in 2019. Using US Census data on 4,000 high-tech startup acquisitions from 1990 to 2011, it found that 33% of acquired workers left within the first year, against 12% of regular hires with similar skills. Those are startups in an older period, so read it as a direction. The 2014 report on TSB's old platform warned of "high key man risk associated with certain critical legacy applications". In a company of forty people, that risk may be one developer who knows why the billing job runs twice on the last day of the month.

Find those people during the review, and sign what you need before the announcement reaches them. Retention money helps for a period; a clear answer about their system's future helps longer. In parallel, get the knowledge out of their heads: pair a second person with them on real tasks, record the deploy and the restore, and repeat the handover test from our article on selling, where a new developer sets the system up from the documents, and each question they had to ask becomes a page to write. On the seller's side this is the founder dependency problem, and it does not go away when the money arrives.

The code came with the deal. The reasons behind it may leave in March.

THE COST

Why synergy figures slip

Here is TSB's bill next to its promise. The comparison is not like for like, since the saving was meant to recur each year and the costs are one-off, but it shows the scale of what a savings case can leave out.

TSB reported a statutory loss of £105.4 million for 2018, against a profit of £162.7 million in 2017. Research points the same way, though consultancies sell this work. Bain wrote in June 2019 that 70% of process and systems integrations fail in the beginning and not at the end, that integration costs overrun estimates by 20% to 50%, and that the worst performers carry IT costs two to three times higher as a share of revenue than the best. The page gives no sample for the 70%, so take it as the firm's experience.

Most slips come from lines nobody put in the model:

We cannot give you a percentage for your deal before seeing the systems. What we would do is move the synergy figure out of the deal model and into the system plan: which system goes off, on what date, saving what, and who owns that date.

An integration goes better when the systems were built to be handed over, and a private equity manager should read this chapter with the next sale in mind, because that buyer's auditors will read what you integrated. The technical review before a sale and the presentation to a buyer rest on this work.

We work this way where we carry the result ourselves. At Schoeffel, a pearl house founded in 1921, we are a strategic partner and hold a percentage of the company. When you build a business the grown-up way, you calculate the scenarios of how it may develop, and a future transaction is built in as one of them: the aim is a company worth hundreds of millions, not tens of millions, with everything ready when the owner needs to exit. That is an aim and work in progress, neither an acquisition nor an integration case. The thinking behind it is in Digital Architecture: How to Build a System That Can Grow With Your Business.

We apply the same eye to ourselves. DeZZign, our own product in architecture and design, receives offers to buy it from time to time. So we put its code, all its documentation and the company's assets in order and replaced all its SaaS with custom systems, looking at them as something a buyer would have to take over, and we tested the pitch and everything around it there on ourselves.

Offers have also been reaching Peretz itself in recent months. As an experiment we packaged our own business the way a buyer's team would have to take it over, with the upgrade to Laravel 13 and PHP 8.4 and the code ownership documents described above. It was an experiment, not a sale.

SMALL DEALS

What a small acquisition can skip

Buying a ten-person company with one product is a different job from TSB. You can skip a programme office, steering boards, a formal TSA if the company stands alone, and usually a clean team if you are not competitors, though your lawyer should confirm that. You can keep most systems separate for a year with no shame. Often the right plan is to secure it and connect the one report you need.

You cannot skip the following, however small the deal:

• Control of the domain, code repository, cloud, payment and analytics accounts, in the company's name.
• Removing access for everyone who has left, and rotating passwords and keys after the handover.
• A tested restore from a backup, and a written inventory of systems and vendors with renewal dates.
• A look at the privacy policy before you touch the customer list.
• A paid handover with whoever holds the knowledge, and a second person who has actually done a deploy.
• A check for a current or past compromise.

A small deal skips the ceremony and keeps the order. If the previous developer has gone or the access is incomplete, begin with a Project Takeover audit, which starts from $2,500 as of November 2026.

THE TEAM

Who does this, and how long it takes

A real integration needs several kinds of people at once. An integration lead with long M&A experience, sometimes licensed, holds the plan and can say no to a date. Analysts read the acquired code and data from top to bottom, without its authors in the room. Then come security specialists, engineers and data engineers, QA who report load tests as they are, a business owner for each system who decides what "right" means, and a lawyer.

One lesson from TSB belongs here. Slaughter and May says the board should have taken independent advice on the whole programme. So treat the buyer's own IT arm as a supplier, and keep someone at the table who gains nothing from a yes.

Timing depends on what you find. The ranges in the FAQ below are our planning view, and only a review of the actual systems can tighten them.

The assessment and the repair are separate things. As of November 2026, our Technical Due Diligence Session costs $1,500 and a full review starts from $7,500, priced on the scope of the business; a Discovery Phase starts from $4,000. Each gives you an assessment and a direction. The integration work that follows has no honest starting price, because we have to see the systems first. If you need someone senior to hold it together part time, a Fractional CTO starts from $3,500 a month for about a day a week, with development priced separately.

The teams are sometimes large, and that is where we have a real advantage. Everything we do is outsourcing or outstaffing, from a large pool of vetted developers of European and Ukrainian origin at reasonable prices, so a dedicated team can be assembled for the months a migration needs. For Neon AI we have been providing Python developer teams for more than six years, as we describe in Outsourcing, Outstaffing or a Dedicated Team; that is team work and not an M&A integration. What we build is shaped around the client's business logic and belongs to the client, with code and deployment handed over under the contract, which matters more than usual when the owner of the business has just changed.

QUESTIONS

Frequently asked questions

How do you integrate IT systems after an acquisition?

Take control of identity, access and monitoring first, while billing, payroll and orders keep running unchanged. In the first 100 days, take a full inventory and decide for each system whether to keep it, connect it, absorb it or replace both. Then move money and customer data, and change the visible front last.

How long does post-merger IT integration take?

In our judgement, months for a small company with few systems, a year or more for a mid-size one, and years for a platform move in a large one. Marriott's planned 18 months became about 27 before the Starwood systems were off.

What is a transition service agreement in IT?

A contract under which the seller keeps providing IT services to the unit it sold, for a fee and a limited period. It is typical when a part of a group is carved out. Write it as an exit plan: each service with an owner, price, exit date, the price after that date, and a knowledge-transfer period.

Should we move the acquired company onto our own systems?

Only where the business logic supports it. Owning a platform shows what is cheap to reuse, not whether the acquired company fits it. Identity usually moves early, a CRM may just be connected, and the core product is often kept and secured for a long time.

Who is responsible for a breach that began before the deal?

From closing, the new owner runs those systems, and regulators address the company holding the data. The ICO fined Marriott for months after GDPR took effect in a Starwood attack that began in 2014. Ask your lawyer what the contract can recover from the seller.

Sources

• UK Information Commissioner's Office: Penalty notice to Marriott International, October 30, 2020
• US Federal Trade Commission: Complaint in the matter of Marriott International and Starwood, 2024
• UK Financial Conduct Authority: Final notice to TSB Bank plc, December 20, 2022
• Slaughter and May: Independent review of TSB's 2018 migration, dated October 31, 2019
• Bain & Company: Process and Systems Integration, a New Source of Competitive Advantage, June 12, 2019