The "Rewrite" Trap
The most expensive mistakes in M&A happen not during diligence but during integration. You can perform a perfect technical assessment, negotiate the right price, close the deal — and then destroy the value you just purchased by botching the integration. The most common way this happens is the "Rewrite Trap."
Scenario:
Your company runs a Java/Spring Boot microservices architecture on AWS with Kubernetes. The target company built their product as a PHP monolith running on bare-metal servers in a colocation facility.
The Trap:
A well-meaning VP of Engineering declares: "We'll rewrite their application in Java and migrate it to our Kubernetes cluster. It'll take six months."
Here's what actually happens:
- Month 1-3: The rewrite team discovers the PHP monolith has 200,000 lines of business logic with no tests and no documentation. "Six months" becomes "eighteen months, maybe."
- Month 4-8: The acquired engineering team is told to "support the rewrite" — meaning they answer questions about their old code while watching it be replaced. Their morale craters. The best engineers start interviewing elsewhere.
- Month 9-12: Key engineers from the acquired team leave. The rewrite team loses their primary source of domain knowledge. Critical business rules are missed or misimplemented.
- Month 13-18: The rewrite is "80% done" (which in software means 50% done). Meanwhile, the original product has received no new features for over a year. Customers who were promised continued innovation start churning.
- Month 24: The project is either cancelled (total loss) or shipped with significant regressions. The acquisition that was supposed to accelerate growth has instead consumed two years of engineering capacity.
The Senior Decision:
Sometimes the best integration strategy is "Leave them alone." This doesn't mean ignoring the acquisition — it means acknowledging that forcing stack convergence destroys more value than it creates. Practical alternatives include:
- API Bridge: Build a well-defined API layer between the two systems. Each team continues to ship in their own stack. Data flows through the API. This is fast to implement and preserves both teams' velocity.
- Strangler Fig Pattern: Gradually replace components of the acquired system one at a time, routing traffic through a facade. New functionality is built in the acquirer's stack; old functionality is migrated incrementally. This takes years but preserves continuity and allows the domain knowledge to transfer organically.
- Shared Platform, Independent Apps: Converge on shared infrastructure (monitoring, CI/CD, cloud provider, identity management) without rewriting application code. This captures operational efficiency without the rewrite risk.
- Acqui-hire with Sunset: If you're really buying the team and not the product, be honest about it. Give the acquired product a defined sunset timeline, communicate it clearly to customers, and move the team to your existing product.
If asked "How would you integrate a newly acquired company's tech stack?", resist the urge to immediately propose a rewrite or migration plan. The strongest answer starts with: "It depends on what we're acquiring — the product, the team, or the customer base — and what the integration timeline expectations are." Then discuss the spectrum from full autonomy to full convergence, and the trade-offs of each. Mentioning the Strangler Fig pattern by name demonstrates architectural maturity. Mentioning that the rewrite trap is the most common failure mode demonstrates operational experience.
Key Point: The integration strategy should be part of the diligence findings, not an afterthought. A TDD report that says "the code is PHP and that's bad" is useless. A TDD report that says "the code is PHP; migration to our Java stack would take 18-24 months and cost $3M in engineering time; we recommend an API bridge strategy with gradual convergence over 3 years, starting with shared observability infrastructure in Q1" is actionable intelligence that leadership can use to make informed decisions and set realistic expectations with the board.