This matrix records what happens to every application in the combined estate: which survives, which is retired, which is selected market by market, and when. It is the single most consequential planning document in the program — the largest synergy source depends on it, the migration schedule is derived from it, and the integration architecture exists to support the coexistence periods it defines. Approved by the Integration Steering Committee on June 26, 2023, before closing, on the basis of system inventories and architecture documentation obtained through diligence.
This is a decision record, not a plan. Each row states what was decided and why, so that a decision can be challenged on its reasoning rather than relitigated from scratch every time someone new joins the program. The migration work implied by these decisions lives in the Cloud Migration Wave Plan and the Interface Build log. A disposition is a decision; a migration is the work. Programs that blur the two end up debating strategy in the middle of a cutover.
Table of Contents
Part I — How Decisions Were Made
Part II — The Matrix
- Core Administration and Claims
- Clinical, Network and Member-Facing
- Corporate and Supporting
- Disposition Summary
Part III — The Arguments
- The Four Contested Decisions (incl. §8.3.1 disaster recovery)
- Options Considered and Rejected
- Changing a Disposition
1. Disposition Taxonomy
| Disposition | Meaning | When it is the right answer |
|---|---|---|
| Absorb | The function moves to ACME's system. The target's system is retired. | Scale economics dominate and neither system holds differentiated capability. The default for commodity functions. |
| Preserve | The target's system becomes the go-forward for the combined entity. ACME's is retired. | The target's capability measurably outperforms and is part of what was bought. |
| Best-of-both | Selection made component by component or market by market rather than wholesale. | Neither estate is uniformly stronger and the components are genuinely separable. |
| Retire | The function ceases. No successor system. | The activity existed only because the target was standalone, or is duplicated by a function that is not itself an application. |
| Replace | Neither system survives. A new capability is procured or built. | Rare, and expensive. Justified only when both estates are inadequate for the combined entity. |
| Coexist | Both run for a defined period; the disposition decision is deliberately deferred. | The information needed to decide is not yet available, and forcing the decision early would be guessing. |
"Coexist" is a legitimate disposition and it is also the one most easily abused. Deferring a decision because the evidence genuinely is not yet available is good judgment. Deferring because the decision is contentious is how programs arrive at eighteen months post-close with two of everything still running and nobody accountable. The discipline that separates them: every coexist row carries a decision date and a named decider. A coexist row without both is an unmade decision wearing a disposition's clothing.
2. The Decision Test
One question was applied to every row, in this order.
- Does combining this function create value, or destroy the value we paid for? If the target's capability is part of the investment thesis, the burden of proof sits with consolidation, not with preservation.
- Is either system materially better for the combined entity? Assessed on capability and operating economics, not on which organization owns it.
- Can the surviving system absorb the combined volume? A correct disposition that the target platform cannot physically support is not a decision, it is a wish.
- What does the regulator, the member or the provider experience? A change that is invisible to all three is cheaper than one that is not.
- Does the timing fit inside the TSA window? The contractual maximum is a wall. A disposition whose migration cannot complete inside it is the wrong disposition regardless of its merits.
The failure mode this test is designed to prevent is "absorb by default." An acquirer's instinct is to consolidate everything onto its own estate, because that is the version its own people understand, and because consolidation is what produces the synergy number. Applied indiscriminately, it migrates the better-performing operation onto the worse-performing one and books the resulting cost saving as a win. The acquirer being larger is not evidence that the acquirer is better at everything. Two rows in this matrix go the other way, and each is argued in Section 8.
3. Coexistence Duration — the Variable That Drives Architecture
Every disposition implies a period during which both systems are live. That period is the single most important number this matrix produces, because it determines what kind of integration is worth building.
| Coexistence period | Appropriate integration | Reasoning |
|---|---|---|
| Under 3 months | Manual process, dual entry, or a tactical file transfer | Engineering effort exceeds the cost of the workaround |
| 3–9 months | Point-to-point interfaces, batch and EDI | Enough duration to justify build, not enough to justify architecture |
| 9–24 months | Integration layer with a canonical model | The band this program sits in. Long enough that point-to-point becomes unmaintainable as interface count grows. |
| Beyond 24 months | Treat as permanent architecture, not as transition | If it will outlive the program, it should be designed as though it will |
This table is the answer to the hardest question an interviewer can ask about this program: "why spend money on middleware for systems you are retiring?" Because the retirement is twelve months away against an eighteen-month contractual limit, and in that window the combined entity must adjudicate claims, enroll members, pay providers and file with regulators across two estates. A tactical bridge built for three months and then operated for eighteen becomes the most fragile thing in the program — and it fails at exactly the moment when everyone is busy with cutover. The coexistence duration decides the architecture, and the TSA term decides the coexistence duration.
4. Core Administration and Claims
| Ref | Application | Disposition | Coexist | TSA | Rationale |
|---|---|---|---|---|---|
| AD-01 | Core administration / claims adjudication | Absorb | 12 months | Yes | Scale economics; largest single synergy component. Target's release loses vendor support inside the window, so retention was never an option. Governs the critical path. |
| AD-02 | Enrollment & eligibility | Absorb | 12 months | Yes | Inseparable from core admin; migrates in the same wave. Depends on member identity resolution completing first. |
| AD-03 | Claims editing & payment integrity | Absorb | 12 months | Yes | ACME's rule set is broader and already tuned for the combined volume. Target's custom edits inventoried and ported where they encode genuine policy. |
| AD-04 | EDI gateway / clearinghouse connectivity | Absorb | 14 months | Yes | ⚠ Retires after core admin, not with it. Trading partner re-registration is externally paced and cannot be compressed by internal effort. |
| AD-05 | Appeals & grievances | Absorb | 15 months | Yes | Longest coexistence in the estate. Open cases must complete in the system that opened them — a regulatory record cannot be migrated mid-case. |
| AD-06 | Fraud, waste & abuse detection | Absorb | 12 months | No | Model performance improves with the larger combined claim history. Consolidation is a capability gain, not only a cost saving. |
5. Clinical, Network and Member-Facing
| Ref | Application | Disposition | Coexist | TSA | Rationale |
|---|---|---|---|---|---|
| AD-07 | Care management platform | Preserve | 18 months | No | ⭐ Target's program measurably outperforms on readmission and chronic-condition engagement. The platform is part of how it performs. ACME's tool retires instead. Argued in §8.1. |
| AD-08 | Utilization management | Best-of-both | 15 months | No | Target's clinical criteria configuration is stronger; ACME's authorization workflow and provider portal integration is stronger. Components are separable. |
| AD-09 | Provider data management | Absorb | 10 months | Yes | A single provider master is a prerequisite for network rationalization. Two provider directories in one entity is a member-facing defect, not an internal one. |
| AD-10 | Network contract management | Absorb | 14 months | No | Migration sequenced against contract renewal dates rather than program convenience — a contract cannot be re-papered mid-term to suit a cutover. |
| AD-11 | Member services CRM | Coexist | Then absorb | Yes | ⭐ Preserved through Day 100, absorbed thereafter. Deliberate: absorbing member-facing operations at Day 1 risks visible service failure at peak regulator attention. Argued in §8.2. |
| AD-12 | Member portal & mobile | Absorb | 13 months | No | Sequenced after ID card reissue so members are not asked to change portal and card in the same period. |
| AD-13 | Broker & employer portal | Absorb | 16 months | No | Timed to the open enrollment cycle. Migrating a broker portal during selling season is a self-inflicted revenue risk. |
| AD-14 | Quality & HEDIS reporting | Absorb | 18 months | Yes | Measurement year boundaries govern. A reporting year must complete in one system or the rates are not defensible to the accrediting body. |
Three rows in this section are paced by calendars nobody in the program controls. Appeals by open-case duration, broker portal by selling season, HEDIS by measurement year. This is characteristic of health plan integration and it catches programs that build schedules from effort estimates alone. You cannot compress an externally governed cycle by adding people to it — and a plan that assumes you can produces a migration date that was never achievable, discovered late.
6. Corporate and Supporting
| Ref | Application | Disposition | Coexist | TSA | Rationale |
|---|---|---|---|---|---|
| AD-15 | General ledger & financial reporting | Absorb | 9 months | Yes | Migrates at a fiscal period boundary. Combined statutory reporting requires a single ledger; among the earliest migrations. |
| AD-16 | Actuarial & underwriting | Absorb | 12 months | No | Single rating methodology is a regulatory requirement for the combined book, not a preference. |
| AD-17 | HRIS | Absorb | 3 months | Yes | Earliest migration in the estate. Associates must appear in one system to be paid, benefited and communicated with. A Day 1 dependency. |
| AD-18 | Payroll | Absorb | 3 months | Yes | Same driver as HRIS, and the least negotiable date in the program. Payroll failure is the one integration defect every employee experiences personally. |
| AD-19 | Identity & access management | Absorb | 6 months | Yes | Prerequisite to cross-entity system access and to the cloud landing zone identity design. Blocks other work; sequenced early. |
| AD-20 | Enterprise data warehouse | Replace | 18 months | Yes | ⭐ The only Replace in the estate. Neither warehouse serves the combined book. Argued in §8.3. ⚠ A new build carries a new recovery obligation — see §8.3.1. Tier 2, and it does not go live without it. |
| AD-21 | Document management & print/mail | Absorb | 8 months | Yes | Vendor consolidation opportunity lands early; among the fastest synergy contributors in the technology estate. |
| AD-22 | Standalone regulatory filing tool | Retire | — | No | ⭐ The only Retire. The tool exists because Cumberland Valley filed as an independent insurer. After entity consolidation there is nothing for it to do. Argued in §8.4. |
7. Disposition Summary
| Disposition | Count | Notes |
|---|---|---|
| Absorb | 17 | The expected majority. Commodity functions where scale is the whole argument. |
| Preserve | 1 | Care management — the capability the transaction was partly undertaken to acquire. |
| Best-of-both | 1 | Utilization management, where the components are genuinely separable. |
| Coexist | 1 | Member services CRM, with a decision date and a named decider. |
| Replace | 1 | Data warehouse. The most expensive decision in the matrix. |
| Retire | 1 | Standalone regulatory filing tool. |
Seventeen of twenty-two absorb, and that ratio is worth defending rather than apologizing for. A mixed integration thesis does not mean an even split; it means each row was decided on its merits rather than by policy. Most health plan applications are commodity functions where running two of them creates cost and nothing else. The thesis earns its keep in the five rows that go another way — and the value of the matrix is that those five can be argued, not that there are many of them.
8. The Four Contested Decisions
8.1 AD-07 Care management — preserving the target's platform over the acquirer's
Decision: Preserve. Cumberland Valley's care management platform becomes the go-forward system for 2,220,000 members. ACME's tool is retired.
| The case for absorbing | The case for preserving |
|---|---|
| ACME's platform already serves four times the membership; scaling it is the known path | Outcomes are what was bought. The target's program measurably outperforms on readmission and chronic-condition engagement. |
| ACME's staff know the tool; no retraining of the larger population | The care model and the platform configuration are not separable. Migrating the model onto different tooling changes the model. |
| Terminating the target's subscription books an immediate saving | The saving is small relative to the medical cost impact of degraded care management across the combined book |
| One fewer platform to operate | Retiring ACME's tool achieves the same consolidation, in the other direction |
The decisive argument is that this is not a symmetrical choice. Both options consolidate to one platform, so the operating saving is broadly the same either way. What differs is which capability survives. Absorbing means paying $1,200,000,000 for a company partly on the strength of its care management, then dismantling the thing that produced the result. Preserving costs the larger organization a retraining program; absorbing costs it the reason for the acquisition. The retraining is expensive and recoverable. The capability is not.
⚠ Practical consequence: this row carries the highest change-management load in the matrix, because it asks the acquirer's own staff to move to the acquired company's system. That is unusual, it is not popular, and the Change & Culture Plan treats it as a named workstream item rather than as an assumption.
8.2 AD-11 Member services CRM — deliberate coexistence through Day 100
Decision: Coexist to Day 100, then absorb. Decision date January 9, 2024. Decider: T. Ruffalo, VP Member Experience.
Absorbing member services at Day 1 was technically feasible and was rejected. In the first weeks after closing, members are receiving new identification cards, providers are verifying eligibility against a changed entity, and the state regulator is attending to a transaction it has just approved. Adding a service-platform cutover to that window concentrates every possible failure into the period of maximum external attention.
This decision knowingly accepts roughly three months of duplicated cost to protect a rank 2 constraint. That trade is exactly what the Charter's constraint priority order authorizes: cost flexes, Day 1 operational integrity does not. Recording the reasoning here matters, because in month two someone will observe that the duplication is wasteful and propose accelerating — and the answer needs to be a decision on the record rather than an argument reconstructed under pressure.
8.3 AD-20 Enterprise data warehouse — the only Replace, and the most expensive decision here
Decision: Replace. Neither warehouse survives.
- ACME's warehouse is dimensioned for its own membership and its own source systems, and would require substantial re-modeling to accept the target's data regardless.
- The target's warehouse is smaller and on infrastructure being retired with the data center.
- The combined entity needs analytics spanning both books of business from Day 1 of the combined reporting year — which neither existing warehouse can produce without the very rework that makes Replace competitive.
- The migration to Azure is happening anyway. Building the target-state warehouse in the cloud rather than lifting an on-premises design into it avoids paying twice.
Replace is the disposition most likely to be a mistake, so it carries the heaviest burden of proof. It means building something new during the period when the organization has the least spare capacity, and it is where integration programs most often overrun. It is defensible here for one reason: the alternative was not "keep what we have," it was "substantially rebuild one of them anyway." When both alternatives require a build, Replace stops being ambition and becomes arithmetic. If that condition had not held, the correct answer would have been Absorb and a slower analytics roadmap.
8.3.1 The obligation that comes with Replace — disaster recovery
A Replace decision creates a system that has never existed, and therefore a recovery capability that has never existed either. Absorbing a function inherits the surviving system's established backup regime, tested runbook and audit history. Replace inherits none of that. It is the one disposition in this matrix that obliges the program to build recovery from nothing — and in a regulated health plan operating on a cloud platform for the first time, a new system without a documented and tested recovery position does not pass a go-live gate and does not survive a compliance review. The cost of that capability belongs in the Replace decision, not in an infrastructure backlog discovered later.
Tiering — the warehouse is not Tier 0, and saying so is the point
Recovery objectives are set by business consequence, not by how important a system feels to the people who run it. Declaring everything critical is the same as declaring nothing critical, because it gives the recovery team no basis on which to sequence.
| Tier | RTO | RPO | Basis |
|---|---|---|---|
| Tier 0 — critical | 4 h | 15 min | Claims adjudication, eligibility 270/271, payroll |
| Tier 1 — essential | 24 h | 1 h | Enrollment, provider data, member portal, ID cards |
| Tier 2 — important | 72 h | 24 h | Care management, utilization management, and the enterprise data warehouse |
| Tier 3 — deferrable | 120 h | 24 h | Document management, internal reporting tools |
For a warehouse, availability and durability are different requirements — and the durability one is what compliance actually turns on. A 72-hour outage of the warehouse is survivable: no claim goes unpaid, no member is denied care, no provider goes unverified. But the warehouse is the system of record for quality measurement and feeds statutory reporting, and losing a measurement year is not recoverable at any RTO, because by the time the loss is discovered the source transactions have aged out of the systems that produced them. That is why this row carries a modest recovery-time objective alongside a strict retention and backup-integrity requirement. A DR conversation that only argues about RTO has missed the thing that would actually end badly.
Gate conditions — evidenced, not asserted
The warehouse does not go live until each of the following is demonstrated. A gate with no evidence attached is an opinion.
- Documented RTO and RPO agreed with the business owner and recorded in the Quality Plan
- Geo-redundant backup configured to the Azure paired region
- Immutable or soft-delete backup protection, against ransomware and accidental deletion alike
- Business Associate Agreement confirmed to cover the backup location and secondary region
- Full restore tested end to end, with evidence retained for audit
- DR runbook with named roles and a named accountable owner
- Recovery obligations carried in the risk register with a residual rating
Backup retention is set at seven years, above the six-year HIPAA floor, driven by state insurance record-retention rules. Restore is tested annually, and the evidence is retained because an auditor asks for the test, not for the policy.
Condition five is the one that gets skipped, and it is the only one that proves anything. Backups configure easily and report success daily; a first-time cloud organization can run a green backup dashboard for a year and still be unable to recover, because nobody has tried. A backup you have never restored is a hypothesis. The first real test of an untested recovery position is the incident, which is the worst possible moment to discover that the retention policy excluded a container, or that the restore takes eleven days, or that the BAA never covered the paired region.
Where the rest of this lands. The recovery design itself is not a disposition matter and does not belong in this document. The tiering and gate conditions above are recorded here because they are a consequence of the Replace decision and must be priced with it. The build detail sits in the Cloud Landing Zone Design, the acceptance criteria in the Quality Plan, the residual exposure in the Risk Register, and the go-live gate itself in the Cloud Migration Wave Plan.
8.4 AD-22 Regulatory filing tool — the row that reminds you a function can end
Decision: Retire. No successor.
Cumberland Valley maintained a tool for producing its own statutory filings as an independent licensed insurer. After legal entity consolidation, Cumberland Valley does not file — ACME does, for the combined entity, using its existing process. The function does not move; it stops.
Worth stating because disposition matrices tend to assume every function must land somewhere. Some functions exist only because the target was standalone: separate statutory filing, a separate board reporting pack, a separate external audit coordination process. Those are not migrations and not consolidations — they are activities that cease when the entity does. Retiring a function outright is usually cheaper and more certain than any migration, which makes it worth actively looking for rather than discovering by accident.
9. Options Considered and Rejected
| Option | Verdict | Reasoning |
|---|---|---|
| Absorb everything to ACME's estate | Rejected | Destroys the care management capability the transaction was partly undertaken to acquire. Simplicity purchased at the cost of the thesis. |
| Run Cumberland Valley as a standalone subsidiary | Rejected | Forgoes the platform and corporate synergies that constitute the majority of the $85,000,000 commitment. The deal does not clear its return threshold on this basis. |
| Retain the target's core platform and migrate ACME onto it | Rejected | The target's release loses vendor support inside the integration window, and it has never run at 2,220,000-member scale. Not a real option once DD-01 was known. |
| Defer all disposition decisions until after closing | Rejected | Deciding is permitted pre-close; only executing is not. Waiting would spend the entire seven-month window and arrive at Day 1 with no plan. |
| Big-bang migration at Day 1 | Rejected | Concentrates every technical risk into the moment of maximum regulatory and member attention, with no rollback that does not itself constitute a service failure. |
| Extend coexistence to the full 18-month TSA maximum | Rejected | Consumes the entire negotiated margin as a plan rather than holding it as protection. The margin exists for problems that have not happened yet. |
The last row is the one worth pausing on. Planning to the contractual maximum looks prudent and is the opposite. Margin negotiated at signing exists to absorb what discovery reveals; a plan that consumes it before discovery has begun has converted protection into schedule and left the program with nothing to spend when something goes wrong. Plan to the target, hold the margin, and treat any of it you spend as a decision the Steering Committee makes explicitly.
10. Changing a Disposition
A disposition may be changed. The process is deliberately more demanding than for an ordinary schedule change, because a disposition reversal invalidates downstream design work in the integration architecture, the wave plan and the synergy model.
| Requirement | Detail |
|---|---|
| Formal change request | Against the Change Control Log, regardless of dollar value |
| Constraint statement | Which constraint the change protects and which it spends, per the Charter's priority order |
| Synergy impact | Quantified against the affected source in the Synergy Realization Plan |
| Architecture impact | Assessed by the Integration Architect — interface work already built against the original disposition |
| TSA impact | Explicit statement of effect on the exit date and the remaining margin |
| Approver | Integration Steering Committee. Not delegable to the Program Manager at any dollar threshold. |
Dispositions are approved by the Steering Committee and can only be changed by it, whatever the cost impact. This is a deliberate departure from the Charter's dollar-threshold model, and the reason is that a disposition's cost is rarely where its consequence sits. Reversing a decision to absorb might cost little in the month it is taken and invalidate nine months of interface build, a migration wave sequence, and a synergy commitment reported to the board. Approval authority here follows blast radius, not price.
Related artifacts: 1 — Integration Charter · 2 — Deal Summary · 7 — Due Diligence Findings · 13 — Synergy Realization Plan · 21 — Vendor & Contract Disposition Matrix · 22 — TSA Schedule & Exit Plan · 25 — Integration Architecture · 35 — Cloud Migration Wave Plan