M&A: Two Codebases, Two Cultures, One Standard
When Company A acquires Company B: Company A has CLAUDE.md with TypeScript strict mode, Drizzle ORM, and Next.js App Router conventions. Company B has .cursorrules with JavaScript (no TypeScript), Mongoose ODM, and Express.js conventions. The codebases must eventually work together. The engineers must collaborate. The AI tools must generate consistent code. But forcing immediate convergence: disrupts Company B's product delivery and alienates their engineering team.
The M&A integration challenge: the acquired team is simultaneously: maintaining their existing product (customers do not stop needing features during an acquisition), learning the parent company's systems and culture, and adapting their conventions to align with the parent company. AI rules provide structure for this process: clear phases, measurable milestones, and a defined end state — without requiring a big-bang rewrite.
The AI rules advantage in M&A: instead of months of manual convention documentation and training, the acquired team receives the parent company's rule files. Their AI tools immediately start generating code in the parent company's conventions. The transition happens organically as new code follows the new rules and old code is updated incrementally.
Phase 1: Technical Assessment (Days 1-30)
Codebase audit: assess the acquired codebase against the parent company's standards. Categories: aligned (already follows the parent company's conventions — no change needed), compatible (different but acceptable — can coexist), divergent (conflicts with parent company standards — needs migration), and superior (the acquired team's approach is better — consider adopting it). AI rule: 'Not everything in the acquired codebase needs to change. Identify what is already good, what can coexist, and what genuinely needs to change. The assessment should produce: a gap analysis and a prioritized migration plan.'
Security assessment (immediate): security standards are non-negotiable. Check: authentication patterns, data encryption, input validation, secrets management, and dependency vulnerabilities. AI rule: 'Security gaps: remediate immediately (within 30 days). Apply the parent company's security AI rules to the acquired codebase. Security is the one area where speed trumps cultural sensitivity — vulnerabilities do not wait for integration timelines.'
Team assessment: understand the acquired team's skill levels, technology expertise, and cultural preferences. Are they experienced with TypeScript (migration to strict mode will be smooth) or JavaScript-only (migration requires training)? Do they use automated testing (integration will be easier) or manual testing (significant process change needed)? AI rule: 'The migration plan must account for the team's current capabilities. A plan that requires skills the team does not have: fails. Include training and support in the timeline.'
The acquired codebase has: hardcoded API keys, unencrypted database connections, and no input validation on user-facing endpoints. These are not convention differences — they are active vulnerabilities. Security rules: applied within 30 days, regardless of the broader integration timeline. The acquired team may feel rushed, but a data breach during the integration period: destroys the value of the acquisition. Security remediation is the one place where speed overrides cultural sensitivity.
Phase 2: Alignment and Migration (Days 31-120)
Phased rule adoption: do not apply all rules at once. Week 1-4: security rules (mandatory, non-negotiable). Week 5-8: coding conventions (naming, formatting, linting — low risk, high visibility). Week 9-12: architecture patterns (error handling, API design, database patterns — higher risk, more impactful). Week 13-16: advanced patterns (testing, observability, deployment — most complex, requires training). AI rule: 'Sequence rules from least disruptive to most impactful. Early wins (formatting, naming) build trust. Later changes (architecture, testing) require the trust that early wins built.'
New code vs existing code: AI rule: 'All new code: follows the parent company's AI rules from the adoption date. No new code in the old conventions. Existing code: migrated when modified (the boy scout rule — leave the code cleaner than you found it). No mass migration of existing code — it is expensive, risky, and does not deliver customer value. The codebase converges organically over 6-12 months as features are built and bugs are fixed.'
Tooling migration: the acquired team may use different tools (Cursor instead of Claude Code, ESLint instead of Biome, npm instead of pnpm). AI rule: 'Tooling migration follows rule adoption. First: apply the rules in the acquired team's existing tools (write .cursorrules alongside CLAUDE.md). Later: migrate tools when the team is ready and the migration adds value. Do not force tool migration and convention migration simultaneously — too much change at once.'
Mass migration of an acquired codebase to new conventions: expensive (hundreds of engineering hours), risky (mass changes introduce bugs), and low-value (does not deliver customer features). The boy scout rule: every PR leaves the code cleaner than it found it. Touching a file to fix a bug? Also update the naming convention in that file. Adding a feature to a module? Also add the missing error handling pattern. Over 6-12 months: the codebase converges organically. No mass migration. No big-bang rewrite.
Phase 3: Convergence and Integration (Days 121-180)
Full integration: by day 180, the acquired team operates within the parent company's governance framework. Their repos: have the standard AI rules, are synced by the rules platform, appear in the compliance dashboard, and follow the governance process for rule changes. AI rule: 'Full integration does not mean identical code. It means: the acquired team operates within the same framework, follows the same governance process, and generates new code that is indistinguishable from the parent company's code. Legacy code differences: acceptable and converging.'
Bi-directional learning: the acquired team brings expertise that the parent company may lack. AI rule: 'During integration: actively look for practices from the acquired team that are better than the parent company's. If the acquired team has better testing practices, better documentation habits, or better performance optimization patterns: adopt those practices into the parent company's rules. M&A integration is an opportunity to improve both organizations, not just conform the acquired team.'
Success metrics: track integration progress with: rule adoption rate (percentage of acquired repos on current rules), new code compliance (percentage of new PRs that pass the rules without override), team satisfaction (are the acquired engineers finding the new rules helpful or burdensome?), and product velocity (is the acquired team still shipping features at the same pace?). AI rule: 'Integration succeeds when: the acquired team is productive with the new rules, product velocity is maintained, and the acquired team feels like part of the organization — not like a conquered territory.'
The ultimate M&A integration metric: is the acquired team still shipping features at the same pace? If rule adoption slows the team from 10 features/quarter to 4: the integration is too aggressive. If the team maintains 10 features/quarter while adopting new rules: the integration is well-paced. Product velocity is the constraint — rule adoption must fit within it, not the other way around. Engineering leadership should track velocity weekly during the integration period.
M&A Integration AI Rules Summary
Summary of the AI rules playbook for post-acquisition technical integration.
- Assessment (Days 1-30): audit codebase (aligned/compatible/divergent/superior). Security gaps: fix immediately
- Team assessment: skills, expertise, cultural preferences. Plan must match team capabilities
- Phased adoption: security (week 1-4) → conventions (5-8) → architecture (9-12) → advanced (13-16)
- New code: parent company rules immediately. Existing code: migrate when modified (boy scout rule)
- Tooling: apply rules in existing tools first. Migrate tools later when team is ready
- Convergence (Days 121-180): full governance integration. Legacy differences acceptable and converging
- Bi-directional: adopt acquired team's better practices into parent company rules
- Success: rule adoption + product velocity maintained + team satisfaction positive