Shared Capabilities in Product Platform Consolidation
An anonymized Ampity account of shared identity, a product portal and selective backend consolidation. Delivery and business outcomes remain unverified.
[Overview] Shared capabilities across acquired products
This anonymized Ampity engagement concerned the consolidation of acquired SaaS products with overlapping capabilities and different application stacks. The original account describes shared identity, a common portal, customer-data integration and selective backend consolidation while some product-specific components remained separate.
The intended customer experience was a common entry point without discarding capabilities particular to each product. The account records that approach and the work described below. It does not establish customer continuity, cost savings, delivery-speed gains or a completed move to one codebase.
[Context] Similar products with different dependencies
The account describes a Rails product with established billing integration, a Node.js/React product and a Django product with enterprise integrations. Separate accounts, customer-data representations and overlapping feature implementations were reasons to consider shared capabilities.
A common interface and a common implementation are different targets. Customers might use one login and portal while product backends remain separate. Combining repositories would not, by itself, establish consistent permissions, compatible data or independent service ownership.
The team-size record is unresolved: the source metadata says 15 engineering teams, while the body says 15 engineers across three teams. Neither is used here as a verified staffing or capacity figure. The stated delivery deadline, feature commitments and customer obligations are planning constraints in the account, not evidence that every obligation was met.
[Decisions] Incremental sharing rather than a forced replacement
The recorded alternatives concerned what to replace and what to retain.
| Alternative | Reason recorded for the decision |
|---|---|
| Rewrite and migrate all customers together | Rejected because the account treated migration disruption, existing delivery and the deadline as constraints. No counterfactual completion date is established. |
| Move everything onto one existing product | Rejected because billing and enterprise capabilities differed across products. The account does not establish that customers would necessarily leave. |
| Extract shared capabilities and migrate incrementally | Chosen to separate a common customer experience from later backend decisions, retaining specialized components where the team chose not to merge them. |
The account calls the incremental approach a strangler-fig strategy. AWS's strangler-fig guidance explains incremental replacement and routing between existing and replacement functionality. That is a general mechanism, not proof of this engagement's routing implementation or an instruction to convert every product to microservices.
Retaining independent products is also a valid comparison when their customers, capabilities or obligations do not justify integration. A consolidation plan should identify the particular shared capability rather than treat fewer systems as its acceptance criterion.
[Design] Identity, interface and backend changes had different boundaries
The identity work is described as a central OAuth 2.0/OIDC service, a canonical user model and adapters for existing user representations. The narrative includes email-based identities, UUIDs and enterprise directory integration. These are recorded integration concerns; matching identifiers does not establish that accounts or permissions can safely be combined.
The portal work is described as a React shell with existing product interfaces embedded or integrated, including iframe-based integration. A shared navigation surface does not establish consistent authorization, session handling or feature behavior across the products. Those require their own definitions and observations.
The backend account describes combining overlapping billing capabilities and standardizing some enterprise-integration adapters. It also describes retaining specialized reporting and compliance-related components separately. That is selective consolidation, not a demonstrated single deployment or repository. No specific legal compliance or certification conclusion follows from the name of a retained component.
[Data boundary] A shared view needed a defined write contract
The original account describes a shared customer-data layer, local copies during transition, product-published changes and subscriptions to updates. It calls the approach event sourcing and describes reconciliation into an authoritative view. It does not supply the event model, write-authority rules, delivery guarantees or reconciliation evidence needed to establish those properties.
Review which system can accept each change, how identifiers map and which representation a reader should use at each stage. A label such as shared data does not answer whether two products can update the same customer or what happens when their updates conflict.
AWS's transactional-outbox guidance explains how a database update and a separate notification can diverge when one operation fails; duplicate delivery and ordering also need consideration. This is a reason to inspect the actual write and delivery contract. It does not establish that an outbox, a particular message broker or an exactly-once effect existed here.
A common database can retain schema and runtime dependencies. AWS's shared-database guidance discusses coordination and backward-compatible changes across service versions. The account's shared-data description does not establish that every product used one physical database.
[Approach] Compatibility and recovery during staged change
The account describes identity, portal, data and backend work as overlapping phases, with customer-by-customer migration and continued product work. Its exact durations, completion date and claimed uninterrupted service are not established here. Parallel activity is a described delivery approach, not a continuity result.
For a comparable migration, review the combinations that coexist: an existing caller against a replacement capability, earlier and later schemas, local and shared representations, and customers at different migration stages. Moving a route changes where requests go. It does not reconcile writes already accepted elsewhere or reverse a schema change.
An earlier application artifact may not understand data written by a newer version. Amazon's rollback-safety discussion explains this mixed-version problem and the need to verify compatible forward and backward transitions. Keeping an old deployment therefore does not establish a state-recovery path.
Before expanding a migration, identify the last compatible release, accepted writes and pending downstream effects. The recovery owner needs a disposition for those records and effects, which may require reconciliation or an approved forward repair. Returning traffic to an earlier endpoint is sufficient only when the relevant compatibility and state conditions have been established. None of those recovery mechanisms is claimed as tested in this engagement.
[Review worksheet] Examine one proposed capability change
Start with authorized read-only review of supplied design records, versioned contracts, sanitized data examples and release evidence. Control-plane or repository access supplies no authority to inspect unrestricted customer records, change routing, run billing operations or modify identities.
Any additional exercise requires an explicitly authorized isolated fixture, synthetic or approved sanitized data, scoped test identities and disconnected production integrations. Use non-delivering receivers for billing, email and enterprise-system effects. Destructive changes, live fault injection and production migration are outside this worksheet. Assign a stop and recovery owner before an exercise.
The following is a proposed worksheet, not an engagement test record.
| Boundary | Read-only evidence or question | Decision owner |
|---|---|---|
| Customer identity | Product-local identifiers, intended canonical mapping, tenant scope and permission rules. Hold the affected mapping if identity or authority is unresolved. | Identity owner |
| Routing and interface | Capability, customer cohort, current/replacement contracts and clients that remain on earlier versions. Hold expansion if required combinations are unknown or incompatible. | Application and release owners |
| Data and writes | Schema versions, accepted-write authority, local/shared copies, pending updates and reconciliation rules. Do not equate copied rows with an agreed current state. | Data owner |
| Recovery | Prior artifact's supported formats, writes after the boundary change and downstream effects needing disposition. Hold a proposed reversal without a compatible state path. | Recovery owner |
| Completion | Capability acceptance, remaining product dependencies and separately owned retirement criteria. Retaining a backend is a recorded choice, not automatic failure. | Product and platform owners |
For a constructed review example, suppose a replacement customer capability can write a representation that the retained product cannot read. A compatible response from the replacement alone would not justify expanding mixed-version traffic or returning writes to the retained product. The worksheet should identify the incompatible reader, affected writes and recovery owner, and hold that proposed transition. This is a stipulated design conflict, not a failure observed in the engagement or a fixture that was run.
Stop an authorized fixture if the target identity changes, a receiver can deliver a live effect, required observations are lost or the approved scope is exceeded. Preserve the observations and use the designated recovery path. A hold on the proposed change is not an instruction to shut down existing products.
[Results boundary] Recorded work and unverified results
The account supports discussion of the described identity integration, portal, customer-data work, adapter approach and selective backend consolidation. It does not substantiate infrastructure savings, reclaimed engineering time, feature throughput, support reduction, staffing changes, customer satisfaction, outage-free migration, certification continuity, revenue protection or investment payback.
Those results need their own definitions, comparable baselines, observation periods and source records. The existence of shared capabilities or fewer visible interfaces does not supply them. The account also leaves the final repository, deployment and data topology unresolved.
[Applicability] Decide what should remain separate
This case is useful when acquired products overlap but retain distinct customer capabilities and integration obligations. The recorded choice was to share selected responsibilities without making complete technical consolidation the sole goal.
Choose one capability for review. Record the customer contract, current owner, intended shared responsibility, versions that must coexist and the state-recovery condition. Resolve that bounded decision before proposing the next consolidation step.
Technical reference
AWS Prescriptive Guidance on strangler-fig migration, transactional outbox and shared databases, plus Amazon's rollback-safety discussion, were read on 17 October 2026. Links accompany general mechanisms and proposed review questions. They do not establish an AWS deployment, the engagement's actual topology, implementation guarantees, completed tests or customer results.