Post-Merger Integration: Where Acquisitions Go to Die

May 25, 2027 · 19 min read

The Harvest Box acquisition is three months old. The Event Storm helped. The API boundary is holding. But the integration isn’t done; it’s entered the long, unglamorous middle where everything takes twice as long as planned and the problems are too boring to make anyone’s priority list.

Charlotte’s 100-day plan ended on day 100. The technology milestones were mostly complete. The operational alignment was mostly done. The people integration was mostly a failure. Charlotte documented this honestly in her retrospective (“we got the systems right and the humans wrong”) and the company absorbed the lesson and moved on.

Except the integration didn’t move on. It stalled.

Six months after the acquisition closed, the Harvest Box systems are still running. Not as the primary system; Greenbox’s platform handles subscriber management, payment processing, and the substitution engine nationally. But the Harvest Box Rails app is still alive on Heroku, handling Sydney-specific delivery logic, the local farm portal that Julian built, and a handful of edge cases in the billing reconciliation that nobody has had time to migrate.

Tom calls it “the ghost.” The system that should be dead but isn’t, because killing it requires understanding it, and understanding it requires Julian, and Julian left in month two.

The honeymoon

The first two weeks after the acquisition were genuinely good.

Maya flew the Sydney team to Perth. They met everyone. They saw the warehouse, the planning onion, the Event Storm photos. Sam ran them through the operational cadence. Tom gave them the technical overview. Jas showed them the brand guidelines and the recipe card process. Marcus talked about the B2B pipeline.

The Sydney team was cautious but engaged. Fiona, the developer, asked sharp technical questions about the API boundary approach. The operations team compared notes with Sam about courier management. The warehouse manager (a quiet man named Greg, forty-three, who’d managed the Marrickville facility since Julian leased it) walked through the Perth warehouse with Sam and pointed out three things they were doing better than Perth. Sam wrote them down.

Julian was there, standing slightly apart, watching his team be welcomed into someone else’s company. He was cooperative and generous with context. He introduced every farm relationship, explained every operational quirk, walked Tom through the codebase’s hidden assumptions. He was the perfect acquired founder: helpful, transparent, and already grieving.

Everyone was excited. The maths worked. The strategy was sound. The people were good. The future was bright.

The future lasted two weeks.

Week three: the first friction

The Harvest Box codebase was a Ruby on Rails monolith running on Heroku. Greenbox’s platform was a Go service running on AWS with bounded contexts, a substitution engine, and four years of architectural decisions recorded in ADRs. The two systems spoke different languages, literally and architecturally.

Tom and Priya designed the API boundary over a weekend. A Go service sat between the platforms, translating requests and responses. Subscriber data flowed from Harvest Box to Greenbox’s central system. Farm availability data flowed from Greenbox’s platform to Harvest Box’s delivery engine. The seam was ugly but functional.

The first friction wasn’t technical; it was data.

Harvest Box stored customer data differently. Not wrong, just differently. Sydney subscribers had fields that Greenbox didn’t use: a delivery-preference notes field where customers wrote things like “leave at side gate, the dog is friendly” or “ring twice, I’m upstairs.” Greenbox’s system had a structured address format. Harvest Box had a structured address plus a free-text notes field that contained years of accumulated customer context.

The API boundary translated the structured data cleanly. The notes field didn’t translate at all. It was lost in the migration: not deleted, just not carried across. Nobody noticed until a Sydney driver rang the office because a customer’s gate was locked and the delivery instructions said nothing about the key under the third pot plant.

Sam noticed first, because Sam always noticed first. She called Greg in Marrickville. Greg explained the notes field. Sam looked at the API boundary specification and found no mention of it.

“Tom,” Sam said, in a message that was calm in the way that Sam’s messages were calm when she was furious. “There are delivery notes for 3,000 Sydney subscribers that aren’t in our system. The drivers need them.”

Tom looked at the API spec. He and Priya had mapped every field in the Harvest Box schema to Greenbox’s schema. The notes field wasn’t in the schema. It was in a separate table, linked by a foreign key that existed in practice but not in the schema definition. One of the undocumented quirks Tom had noted during the technical due diligence and then, in the pressure of the integration timeline, forgotten.

Fiona fixed it in an afternoon. She knew the codebase. She knew where the notes lived, how they were linked, and which ones were current versus historical. She wrote a migration script, tested it against a backup, and had the notes flowing through the API boundary by end of day.

The fix took four hours. The damage (three days of Sydney deliveries without driver notes, sixteen customer complaints, one lost subscriber who’d waited forty minutes for a delivery that never came because the driver couldn’t find the apartment entrance) took longer to repair.

Sam called Tom that evening. “The delivery notes are the difference between a box on a doorstep and a box in the right hands. How did we miss them?”

Tom didn’t have a good answer. He’d mapped the schema. He’d been thorough. But “thorough” meant mapping what was in the schema, not what was adjacent to it. The notes lived in a parallel table that Julian had added six months into Harvest Box’s life, when the first drivers started complaining that they couldn’t find apartment entrances and locked gates. It was a patch, not a feature. It worked because Julian understood his own system’s archaeology. Tom, mapping the system from outside, saw the schema and missed the sediment.

This is the pattern that makes integration treacherous. Every system has two layers: the documented layer (the schema, the API, the codebase) and the accumulated layer (the patches, the workarounds, the human knowledge that fills the gaps the documentation doesn’t cover). Due diligence examines the first layer; integration collides with the second.

Month two: Julian leaves

Julian’s departure was the first fracture the team couldn’t fix with code.

He’d agreed to a six-month transition period. He lasted two months. The reasons were personal and structural and both entirely predictable. Diane had warned Maya that acquired founders rarely survive inside the acquiring company, and Charlotte had added “founder emotional transition” to the risk register as an afterthought that should have been a headline.

Julian didn’t leave because he was unhappy with how Greenbox treated him. He left because there was nothing left for him to do. The farm visits were being taken over by Ben Morrison, who was managing Greenbox’s national farm programme. The subscriber management was handled by the platform. The operational decisions were made by Sam’s team. Julian was a founder with no company to found.

But Julian was also the knowledge. Not the documented knowledge (the decision tables and the API spec and the farm records captured the structured information). Julian was the undocumented knowledge. The three farmers in the Blue Mountains who only dealt with Julian personally. The courier driver who gave Harvest Box priority because Julian had helped him move house one Saturday. The cafe owner in Marrickville who stored overflow produce in his cool room when the warehouse was full, in exchange for Julian dropping off a free box every Friday.

When Julian left, three things happened in the same week.

The Blue Mountains farmers stopped returning calls. Ben tried. He drove out, introduced himself, brought a Greenbox box as a gift. Two of the three were polite but noncommittal. The third said, plainly, “I dealt with Julian. I don’t know you.” The supply from those three farms (stone fruit, heritage apples, and speciality honey) dried up within a month.

The priority courier arrangement ended. The driver had no obligation to Greenbox. He’d done Julian a favour because Julian had done him one. Greenbox was a corporate account, not a personal relationship. Delivery windows for Sydney suburban routes stretched from two hours to four.

The cafe owner in Marrickville stopped answering calls about the overflow storage. Greg, the warehouse manager, handled it by renting additional cold storage from a commercial facility at three times the cost. The cool-room arrangement had been saving Greenbox $2,000 a month. Nobody had documented it because it wasn’t a contract. It was Julian, knowing a bloke.

Month three: the parallel systems

Charlotte’s 100-day plan had the platform migration (moving Sydney subscribers from the Harvest Box Rails app to Greenbox’s Go platform) scheduled for days 61 to 100. Tom’s API boundary approach had already pushed this timeline out. By month three, the migration was “in progress,” which in practice meant that both systems were running simultaneously and nobody was confident enough to turn the old one off.

The parallel systems created parallel problems.

Billing discrepancies ran at two to five per week. A subscriber would update their payment details on the Greenbox platform, but the Harvest Box system (still handling some Sydney billing logic) would attempt to charge the old card. The API boundary was supposed to sync payment data bidirectionally, but edge cases kept appearing: a card that expired between sync cycles, a subscriber who cancelled and re-subscribed within the same day, a payment processor timeout that left one system thinking the charge succeeded and the other thinking it failed.

Each discrepancy was individually minor: a duplicate charge here, a missed charge there. Sam’s team resolved them manually, case by case, apologising to subscribers and adjusting accounts. But the cumulative effect was erosion. Sydney subscribers who’d been with Harvest Box for two years (who’d trusted Julian, who’d been promised that the acquisition would be seamless) were getting emails from two different systems, seeing two different billing dates, and occasionally being charged twice for the same box.

The subscriber data was also fragmented. Some Sydney subscribers had Greenbox accounts. Some had Harvest Box accounts. Some had both, because the API boundary had created a Greenbox record for every Harvest Box subscriber, but 400 of those subscribers had also signed up directly on Greenbox’s website when the Sydney launch was announced, creating duplicate profiles with different email addresses, different preference settings, and different billing histories.

Priya spent a full week writing a deduplication script. She found 412 duplicates. Resolving them required human judgement: which email address was current, which preferences were correct, which billing history was authoritative. Sam’s team resolved them one by one.

Month four: the team shrinks

By month four, half the acquired team had left.

Two operations staff resigned in week six. Two customer service reps followed in week eight. Julian left at the end of month two. Of the original eight Harvest Box employees, four remained: Fiona (developer), Greg (warehouse manager), and two new operations hires that Sam recruited to replace the departures.

The departures weren’t dramatic. Nobody slammed a door or sent an angry email. They left the way people leave when they don’t feel like they belong: quietly, politely, with two weeks’ notice and the standard Australian “taking other opportunities.”

Sam, who’d spent weeks building relationships with the Sydney ops team, knew the real reasons. The Greenbox processes felt imposed, not shared. The cultural distance was enormous. Eight people who’d known everything about their company, who’d made decisions by walking across a warehouse floor, were now inside a fifty-person organisation with squad structures and sprint cadences and a management layer that had meetings about meetings. The culture at distance problem was acute for people who’d never chosen to be distant.

Charlotte documented the departures in her retrospective. “We planned for technology integration and operational alignment. We didn’t plan for identity. The Sydney team lost their company’s name, their founder, their processes, and their autonomy. We gave them Greenbox’s systems. We didn’t give them a reason to stay.”

Month six: the ghost

Six months after the acquisition, the integration was “done” in the way that things in software are done, which means mostly done with a list of known issues that everyone has agreed to live with.

The Harvest Box Rails app was still running on Heroku. Tom had migrated seven of ten capabilities to the Greenbox platform. The remaining three (Sydney-specific delivery routing, the local farm portal that Julian built, and a legacy billing reconciliation job that ran every Sunday at midnight) were still on the old system. Moving them required understanding Julian’s code at a level that only Fiona could manage, and Fiona was now embedded in the Perth engineering team, working on the national platform rebuild, and had limited bandwidth for archaeology.

The ghost cost Greenbox $1,200 per month in Heroku hosting. It cost more in cognitive overhead: Tom’s team had to remember that Sydney had two code paths for certain operations, that the Sunday reconciliation job needed to be monitored separately, that the farm portal for three remaining Sydney suppliers ran on a different stack with different credentials and different logging.

Priya, who maintained the monitoring dashboards, added a note to the Sydney section: “Legacy system active. Do not touch unless you’ve spoken to Fiona.” The note was a monument to the integration’s incompleteness: a warning label on a system that should have been decommissioned months ago.

The subscriber impact

Of Harvest Box’s original 3,000 subscribers, 2,700 were still active at month three. By month six, the number was 2,550. A 15% churn rate over six months, significantly higher than Greenbox’s normal churn rate of 3.8% monthly.

The churn wasn’t catastrophic. Some of it was natural: subscribers who would have left regardless of the acquisition. Some was attributable to the billing discrepancies, the duplicate accounts, the two-week period where the automated and manual substitution processes conflicted. Some was attributable to something harder to measure: the loss of the personal touch that Julian’s small company had provided.

Harvest Box subscribers used to get a box with a handwritten note from Julian. Not every week; Julian didn’t have time for three thousand handwritten notes. But new subscribers got one. Subscribers who’d been there for a year got one on their anniversary. Subscribers who complained got a personal call from Julian, who would apologise and sometimes drive a replacement box over himself.

Greenbox replaced this with Sam’s customer service processes, Jas’s recipe cards, and the automated email flow. The quality was higher. The scale was better. The personal touch was gone.

A subscriber named David Chen (no relation to Maya) emailed after month four. His message was polite and specific: “I subscribed to Harvest Box because Julian knew my name. Your boxes are better. Your service is more reliable. But I don’t feel known. I feel like a subscriber number.”

Sam forwarded the email to Maya. Maya read it and sat with it for a long time. She thought about Mrs Patterson, who’d been subscribed since week three, whose beetroot preference she’d added to the decision tables by hand. Mrs Patterson felt known because Maya had known her, personally, in the early days when every subscriber was a person with a name and a story.

David Chen had had that with Julian. Now Julian was gone and nobody had replaced the knowing.

The billing reconciliation at midnight

The Sunday midnight reconciliation job deserves its own mention, because it’s the purest example of integration archaeology.

Julian wrote the job in month three of Harvest Box’s existence. It runs every Sunday at midnight, queries the Stripe payment records, cross-references them with the Harvest Box subscription database, identifies discrepancies, and generates a report that emails Julian.

Julian hasn’t been at Harvest Box for four months. The job still runs. The report still emails Julian’s old address, which now forwards to a shared inbox that Sam monitors. The discrepancies it identifies are mostly noise: artefacts of the dual-system billing that the API boundary handles during the week. But occasionally, about once a month, the job catches something real: a subscriber whose payment failed on the Greenbox side but succeeded on the Harvest Box side, creating a double charge that neither system detects on its own.

The job is ugly. It’s a Ruby script with hardcoded Stripe API keys and database connection strings that reference a Heroku PostgreSQL instance. The code has comments like “# TODO: fix this properly” and “# Julian knows why this works.” The test coverage is zero. The monitoring is the email to a forwarding address.

Tom wants to kill it. Priya wants to kill it. Fiona says: “Don’t kill it until you understand what it catches. I helped Julian write it. The edge cases it handles are real.”

So the ghost persists. Not because anyone wants it to, but because nobody has the time, the context, or the confidence to turn it off. The cost of the ghost ($1,200 per month in hosting, plus the cognitive overhead of maintaining awareness of a system that should be dead) is less than the cost of the edge cases it catches. For now.

This is integration’s long tail. The dramatic decisions happen in month one. The technology migration happens in months two through six. The ghost lives forever, or until someone schedules the archaeology into a sprint and gives Fiona two weeks to exhume what’s left.

What the integration teaches

Diane ran the business retrospective. Charlotte facilitated. Tom, Sam, Priya, Fiona, and Marcus attended.

The lessons were clear and painful.

People first, systems second. Charlotte’s 100-day plan tracked technology and operations. It should have tracked relationships, morale, and belonging. The two operations staff who left in week six might have stayed if someone had spent the first two weeks asking them how Harvest Box worked, instead of the first two weeks telling them how Greenbox worked. The Event Storm in week four helped, but by week four the damage was done.

Knowledge before code. Julian’s departure took undocumented knowledge with him. The Blue Mountains farmers. The courier arrangement. The cafe cool room. None of this was in any system. All of it was in Julian’s head. The due diligence assessed the technology, the finances, and the subscriber data. It didn’t assess the tacit knowledge: the relationships, the informal arrangements, the things that existed because one person knew the right people.

Diane named this explicitly: “Due diligence tells you what you’re buying. Integration determines whether you keep it. We bought $800K of subscribers, technology, and farm relationships. We kept the subscribers and the technology. We lost half the farm relationships because they were Julian’s, not Harvest Box’s.”

Customers before technology. The billing discrepancies, the duplicate accounts, the missing delivery notes: each was a technology problem that created a customer problem. The API boundary was architecturally sound. The migration approach was technically correct. But the customers experienced it as confusion, duplicate charges, and boxes delivered to the wrong entrance.

Tom’s API boundary approach was the right technical decision. Charlotte’s gradual migration was the right operational decision. But neither of them prioritised the customer experience of the migration itself. The systems were migrated capability by capability. The customers experienced all the capabilities at once: a single, confusing transition from “the company I subscribed to” to “a different company’s systems.”

Integration is its own discipline. Greenbox approached the acquisition with the skills it had: engineering scaling (Charlotte), business strategy (Diane), operations (Sam), technology (Tom). None of them had done a post-acquisition integration before. They applied their existing frameworks to a new problem and got the parts their frameworks addressed right, and the parts their frameworks didn’t address wrong.

The playbook for future acquisitions, if there are future acquisitions, needs a different structure. Charlotte wrote it into her notes:

Week 1-2: Listen. Ask the acquired team how they work. Map their processes alongside yours. Run an Event Storm on day one, not day twenty-eight.

Week 2-4: Relationships. Identify every key person, every informal arrangement, every undocumented dependency. Get them on paper before people leave.

Week 4-8: Customer experience. Design the migration from the customer’s perspective. What will they see? What will change? What will stay the same? Communicate early and often.

Week 8-12: Technology. Migrate systems only after the people are settled and the customer experience is protected.

Throughout: Check in. Not just with the acquired team’s manager. With every person. Weekly. “How are you? What do you need? What’s not working?”

Fiona

Fiona stayed.

She stayed because Tom treated her like a colleague, not a relic. He didn’t rewrite her code. He wrapped it in an API boundary and asked her to help design the integration. He valued her Ruby expertise even though Greenbox’s stack was Go. He included her in architecture discussions and listened when she said things like “the manual substitution process catches edge cases your engine misses.”

Fiona is now part of the national engineering team. She works on the platform alongside Priya, contributes to ADRs, and runs the Sydney delivery domain. The insight she brought from Harvest Box, that the 10% of substitution decisions that don’t follow patterns need a human in the loop, became a feature in the substitution engine. The hybrid approach, automated engine plus human review for edge cases, reduced substitution complaints by 30% nationally.

Greg stayed too. He runs the Marrickville warehouse, which is now the highest-performing logistics node in the network. Sam credits the Sydney delivery notes field (the one that was almost lost in the migration) with a significant chunk of that performance. “Greg’s drivers know things about Sydney customers that our system doesn’t capture,” Sam says. “The delivery notes are the difference between a box on a doorstep and a box in the right hands.”

The ghost, six months later

The Harvest Box Rails app is still running on Heroku. The last three capabilities (Sydney delivery routing, the local farm portal, and the Sunday reconciliation job) are scheduled for migration in quarter two. Fiona has scoped it. Tom has reviewed the scope. Priya has added it to the platform team’s roadmap.

The ghost will die eventually. Every ghost does. But it will leave traces in the codebase: a comment that says “legacy Harvest Box field, do not remove,” a database column that nobody uses but nobody deletes, a configuration value that references a Heroku dyno that hasn’t existed in months.

These traces are the archaeology of integration. They tell the story of two systems becoming one, imperfectly, over time. They’re the code equivalent of the delivery notes field: context that doesn’t fit neatly into a schema but matters to the people who have to work with it.

Integration is where acquisitions go to die. Not because the technology fails. Not because the maths was wrong. Because acquiring a company means buying a living system (people, relationships, knowledge, habits, and history) and treating it as a technology migration.

Greenbox learned this the expensive way. Half the team left. Julian’s knowledge walked out the door. Three farm relationships went cold. Four hundred and twelve subscribers had duplicate accounts. The billing discrepancies numbered in the hundreds.

And yet. The subscribers stayed, mostly. The technology merged, eventually. Fiona improved the national product. Greg runs the best warehouse in the network. The Sydney market, which would have taken six months and $400K to enter organically, was live in three months with 2,550 paying subscribers.

The acquisition worked. The integration was the cost. The lesson is that those are different things, and the second is harder, slower, and more human than anyone expects.

These posts are LLM-aided. Backbone, original writing, and structure by Craig. Research and editing by Craig + LLM. Proof-reading by Craig.