Product Platform Consolidation for Acquisition Integration

Merged three acquired product codebases into unified platform while maintaining customer continuity.

[Overview] System Overview

Post-acquisition integration often fails because it underestimates technical complexity. Three products built by three teams with three technology stacks do not merge without significant effort.

This case examines the consolidation of three acquired SaaS products into a unified platform. Each product served similar markets with overlapping features. The business case for consolidation was clear. The execution path was not.

The timeline was 18 months. Customer retention was critical. Any disruption to existing customers would undermine the acquisition rationale.

[Context] Situation before

Three products. Three architectures. Three deployment pipelines. Three support teams. The cost of running parallel systems was unsustainable.

##### Product A

Built on Rails. Oldest codebase. Largest customer base. Slowest development velocity.

##### Product B

Built on Node.js with React. Most modern stack. Strongest growth trajectory. Smallest team.

##### Product C

Built on Python Django. Best data capabilities. Enterprise customer focus. Most complex integrations.

##### Common Problems

No shared authentication. Customers needed separate accounts per product.

No data portability. Migrating customers between products required manual work.

Duplicate features with different implementations. Maintenance burden multiplied by three.

[Diagnosis] The real problem

The visible problem was three products instead of one. The obvious solution was to pick a winner and migrate everyone to it.

That approach would fail. Each product had capabilities the others lacked. Product A had mature billing integration. Product B had the best user experience. Product C had enterprise compliance features. No single product was ready to absorb the others.

##### The Deeper Issue

The real challenge was defining what "one platform" meant. Was it one codebase? One deployment? One database? One URL? Each definition implied different work, different risks, and different timelines.

The team needed to separate logical consolidation from physical consolidation. Customers needed a unified experience. The backend could remain distributed longer.

Understanding the root cause changed everything.

[Boundaries] Working constraints

Constraints are features, not obstacles. They guide design decisions.

[Decisions] Key tradeoffs

status="rejected" title="Big bang rewrite" description="Build new platform from scratch. Migrate all customers at once." reasoning="Too risky. 18-month timeline insufficient. Customer disruption unacceptable." /> status="rejected" title="Pick a winner" description="Enhance Product B (best stack) with features from A and C." reasoning="Product B lacks enterprise features. Migration would lose Product C customers." /> status="chosen" title="Strangler fig with shared services" description="Extract shared capabilities. Build unified layer. Migrate products incrementally." reasoning="Reduces risk. Maintains customer continuity. Enables parallel development." />

[Design] Architecture design

The architecture introduced a shared services layer between customers and product backends. Unified authentication, billing, and data access. Products remained separate but appeared unified.

###### Platform Consolidation Architecture

Unifying fragmented product platforms into shared core

product-platform-consolidation

"type": "system-context", "title": "Unified Platform Architecture", "description": "Shows how shared services layer creates unified experience over separate product backends.", "components": [ "name": "Unified Portal", "type": "user", "description": "Single customer entry point" }, "name": "Identity Service", "type": "service", "description": "Shared authentication" }, "name": "Billing Service", "type": "service", "description": "Unified billing" }, "name": "API Gateway", "type": "service", "description": "Routing layer" }, "name": "Product A Backend", "type": "service" }, "name": "Product B Backend", "type": "service" }, "name": "Product C Backend", "type": "service" }, "name": "Shared Data Layer", "type": "database" } ], "connections": [ "from": "Unified Portal", "to": "Identity Service", "label": "Auth" }, "from": "Unified Portal", "to": "API Gateway", "label": "Requests" }, "from": "API Gateway", "to": "Product A Backend", "label": "Route" }, "from": "API Gateway", "to": "Product B Backend", "label": "Route" }, "from": "API Gateway", "to": "Product C Backend", "label": "Route" }, "from": "All Backends", "to": "Shared Data Layer", "label": "Customer data" }, "from": "All Backends", "to": "Billing Service", "label": "Usage events" } ], "boundaries": [ "name": "Shared Services", "contains": [ "Identity Service", "Billing Service", "API Gateway", "Shared Data Layer" ] } ] }

{/* Diagram: sequence - Migration Sequence */}
{/* ```json
{
  "type": "sequence",
  "title": "Migration Sequence",
  "description": "Shows the order of capability extraction and customer migration.",
  "components": [
    {
      "name": "Phase 1",
      "type": "boundary",
      "description": "Shared identity"
    },
    {
      "name": "Phase 2",
      "type": "boundary",
      "description": "Unified portal"
    },
    {
      "name": "Phase 3",
      "type": "boundary",
      "description": "Data consolidation"
    },
    {
      "name": "Phase 4",
      "type": "boundary",
      "description": "Backend consolidation"
    }
  ],
  "connections": [
    {
      "from": "Phase 1",
      "to": "Phase 2",
      "label": "4 months"
    },
    {
      "from": "Phase 2",
      "to": "Phase 3",
      "label": "5 months"
    },
    {
      "from": "Phase 3",
      "to": "Phase 4",
      "label": "6 months"
    }
  ],
  "boundaries": []
}

[Approach] Execution model

The 18-month timeline demanded parallel workstreams. Four overlapping phases kept progress visible while managing risk. Each phase delivered standalone value, ensuring the investment paid off even if later phases were delayed.

##### Phase 1: Shared Identity (4 months)

Built central identity service using OAuth 2.0 and OIDC. Migrated authentication for all three products without changing their user-facing flows. Customers gained single sign-on but otherwise noticed nothing different.

Challenge: Each product had different user models. Product A stored users in PostgreSQL with email as primary key. Product B used MongoDB with UUIDs. Product C had LDAP integration for enterprise customers.

Solution: Created canonical user model that mapped to all three. Legacy adapters maintained backward compatibility. Migration ran customer-by-customer over 6 weeks.

Key lesson: Shared identity was the right first step because it touched authentication but not application logic. Low risk, high visible value.

##### Phase 2: Unified Portal (5 months)

Created single entry point at unified domain. Products embedded as modules within React-based portal shell. Customers saw one interface with tabs for each product capability.

Challenge: Three different frontend frameworks. Product A used jQuery. Product B used React. Product C used Angular. Full rewrite was not feasible in timeline.

Solution: Micro-frontend architecture with iframes for Products A and C. Product B integrated natively. Shared navigation and notification layer coordinated between frames.

Key lesson: Perfect architecture was less important than working solution. The iframe approach was inelegant but shipped on time. Replacement was planned for future phases that were never needed.

##### Phase 3: Data Consolidation (5 months)

Extracted customer data to shared data layer. Products read from shared layer but kept local copies during transition. This enabled cross-product features for the first time.

Challenge: Data models were incompatible. Product A had flat customer records. Product B had nested objects. Product C had normalized tables with complex joins.

Solution: Shared data layer used event sourcing. Each product published changes. Central service reconciled and maintained authoritative view. Products subscribed to updates.

Key lesson: Data consolidation was the highest-risk phase. Dual-write during transition caught inconsistencies early. Six-week parallel running period validated correctness before cutover.

##### Phase 4: Backend Consolidation (4 months)

Merged overlapping backend services. Product A and B billing consolidated into single service using Stripe. Product C enterprise integrations (Salesforce, SAP) standardized on common adapter pattern.

Strategic decision: Not all backends merged. Product A report generation remained separate. Product C compliance engine was too specialized. Consolidation stopped when ROI turned negative.

Key lesson: Know when to stop. Full technical consolidation was never the goal. Business consolidation (unified brand, support, billing) was achieved. Technical debt remained acceptable.

##### Cross-Cutting Concerns Throughout

Feature delivery continued in parallel. Each product team spent 60% on consolidation, 40% on new features. This prevented customer complaints about stalled innovation.

Communication: Weekly stakeholder updates showed progress through simple metrics. Customers migrated, features unified, cost savings realized.

Risk management: Each phase had explicit rollback plan. Phase 2 experienced two rollbacks before stable deploy. This was expected and planned for.

[Results] Measurable outcomes

The consolidation achieved its business objectives while teaching valuable lessons about technical integration at scale.

##### Customer Experience

Single login for all products. Unified billing. Consistent support channel.

Customer satisfaction scores remained stable through migration (NPS: 42 before, 44 after).

Zero customer-facing outages during any phase transition.

Support ticket volume dropped 35% as confusion about multiple products eliminated.

##### Operational Efficiency

Support team consolidated from 3 teams (18 people) to 1 team (8 people) without layoffs (attrition and redeployment).

Infrastructure costs reduced 45% through shared services and eliminated redundancy.

Deployment pipelines reduced from 3 to 1 primary with 2 legacy pipelines for specialized Product C compliance deployments.

On-call rotation unified. Engineers now carry one pager instead of three.

##### Development Velocity

Shared services reduced duplication. Features like password reset, audit logging, and usage metering built once instead of three times.

New features deployed to all products simultaneously. Time-to-market for cross-product features dropped from "impossible" to 4-6 weeks.

Engineering teams freed 30% of time previously spent on maintenance of parallel systems.

##### Timeline and Budget

Completed in 16 months-2 months ahead of 18-month deadline.

Full consolidation (single codebase) deferred as diminishing returns. The remaining technical debt was acceptable given the business value achieved.

Total investment: $1.8M in engineering time. Projected 3-year savings: $4.2M. ROI achieved in 14 months.

title="Key improvements achieved:" items={[ "System handles 10x burst load without degradation", "Delivery latency reduced from seconds to milliseconds", "Zero message loss during traffic spikes", "Operational complexity reduced by 60%" ]} />

[Anti-patterns] What could have gone wrong

##### Big Bang Rewrite

Timeline would slip to 30-36 months based on industry data on rewrites of this complexity.

Features would freeze during rewrite. Competitors would capture customers during the gap.

Edge cases from 3 products would be lost. Post-launch incidents would erode customer trust.

The 18-month financial deadline would be missed, affecting the acquisition earn-out and parent company reporting.

##### Pick a Winner

Enterprise customers from Product C would leave. SOC 2 and HIPAA compliance were specific to Product C. Migration to Product B would require 6-month re-certification that customers would not wait for.

Product A customers relied on specific billing integrations that Product B lacked. Revenue from those customers ($2.4M ARR) would be at risk.

Engineering resentment as two of three teams would have their work declared "legacy." Attrition would spike.

##### Do Nothing

Without consolidation, the parent company would continue operating three separate products with three support teams.

Infrastructure costs would continue at $380K/month instead of $210K/month.

Cross-sell opportunities between products would remain friction-filled. Sales cycles would stay long.

The acquisition rationale (operational synergies) would never materialize.

variant="yellow" title="" items={[ "Over-engineering the initial solution", "Ignoring operational constraints during design", "Premature optimization without load testing", "Skipping failure mode analysis" ]} />

[Applicability] Where this pattern applies

##### This Approach Works Well When

Post-acquisition product consolidation with similar but not identical products.

Multiple products with overlapping features where customer segments have different needs.

Customer continuity is critical-cannot afford churn during transition.

Timeline pressure prevents ground-up rewrite.

Each product has capabilities worth preserving.

##### This Approach Is Overkill When

Products serve genuinely different markets with no customer overlap.

No overlapping features to consolidate-products are complementary, not competing.

Greenfield opportunity where legacy can be abandoned without customer impact.

Timeline is unlimited and resources abundant for clean rewrite.

##### Who Should Use This

Private equity or strategic acquirers integrating portfolio companies.

Engineering leaders inheriting multiple products from acquisitions.

Platform teams tasked with creating shared services across product lines.

##### Who Should Not Use This

Companies acquiring products to sunset them.

Teams that lack experience with incremental migration patterns.

Organizations where political dynamics prevent honest assessment of product strengths.

Every system is different. Context always matters.