Post-Acquisition Technology Risk and Continuity Checklist

Most acquisitions fail to deliver their expected value, with studies putting the failure rate between 70% and 90% (Christensen, Alton, Rising and Waldeck, "The Big Idea: The New M&A Playbook," Harvard Business Review, March 2011). Synergies that are not captured in the first full budget year after consolidation often fail to materialize (Christofferson, McNish and Sias, "Where mergers go wrong," McKinsey Quarterly, May 2004). The deal is a legal event. Integration is a technology event: applications nobody documented, data nobody governs, a Transition Services Agreement (TSA) clock that does not stop, and a team that has to keep revenue systems running while everything changes underneath them.

This checklist covers five risk domains. Each has yes/no questions a CIO or CTO should be able to answer before Day 1. Every item carries a severity tag:

• Critical: must be answered before you commit to a plan
• High: delays synergy
• Moderate: increases cost

A "no" or "don't know" on a critical item should be resolved before you commit to a cutover plan. Access, security and system ownership must be settled by Day 1.

Domain 1: Application portfolio risk

Undocumented dependencies, end-of-life frameworks, committed secrets.

1. Do you have a current inventory of every application, including owner, hosting and data it touches? Critical
2. Are inter-application dependencies mapped, including batch jobs, file drops and scheduled scripts? Critical
3. Have you scanned code repositories for committed secrets, keys and credentials? Critical
4. Have you confirmed that software licenses and key vendor contracts transfer under the change of control? Critical
5. Do you know which applications run on end-of-life frameworks or unsupported runtimes? High
6. Have known CVEs been scanned and ranked by exposure across the acquired codebase? High
7. Is there a documented owner for every application that has no active development team? High
8. Do you know which applications are duplicates of ones you already run? Moderate
9. Is there a decision (retain, migrate, retire) recorded for each application? Moderate

Domain 2: Data governance risk

Fragmented sources, conflicting schemas, ungoverned access.

1. Can you list every system of record for customers, products and financials in the acquired company? Critical
2. Do you know who has access to production data today, and is that access reviewed? Critical
3. Are regulated data types (PII, payment, health) identified and located? Critical
4. Is there a plan for identity and tenant consolidation, and a defined security trust boundary between the two environments? Critical
5. Are conflicting schemas and definitions for the same entity (customer, order, SKU) documented? High
6. Is there a plan for which source wins when records conflict? High
7. Can reporting from both companies be reconciled to a single set of metrics? High
8. Is data lineage known for the ten most important reports? Moderate
9. Is there a governed access model ready for AI and analytics use of the combined data? Moderate

Domain 3: TSA compliance risk (carve-outs)

Applies when you acquire a division and the seller keeps providing shared services. Skip if you bought a whole company. Missed deadlines, scope creep, cost overruns.

1. Is every TSA service mapped to a named system, owner and exit date? Critical
2. Is there a cutover plan for each service that ends before its TSA expiry, with buffer? Critical
3. Do you know the cost of extending each TSA service, and who approves it? High
4. Are service levels in the TSA measured, or only assumed? High
5. Is change to TSA scope controlled through a single approval path? High
6. Are hidden dependencies on the seller's shared services (identity, email, network, ERP) identified? High
7. Is the TSA exit tracked weekly against plan with a named executive owner? Moderate
8. Do you have a budget line for TSA overruns? Moderate

Domain 4: Operational continuity risk

Outages during cutover, lost institutional knowledge.

1. Has each cutover been rehearsed in a production-like environment? Critical
2. Is there a tested rollback for every revenue-critical system? Critical
3. Have the systems been load tested at real peak volume, not average? Critical
4. Can financial close and audit trails (SOX or equivalent) continue uninterrupted through cutover? Critical
5. Do you know which people hold knowledge no document captures? High
6. Is knowledge from departing staff captured before their last day? High
7. Are monitoring and on-call coverage in place for acquired systems from Day 1? High
8. Are customer-facing communications and support scripts ready for cutover windows? Moderate
9. Is there a post-cutover stabilization period with defined exit criteria? Moderate

Domain 5: People and execution risk

Knowledge loss, overloaded teams, unclear leadership.

Integrations are run by people, and the acquired team is usually the most stretched group in the deal. Some will lose their roles. Some hold knowledge no document captures, and may hesitate to share it when they know their jobs are ending. The leader running the migration needs to handle that honestly: acknowledge what the team is going through, and push back on executives when the plan would overload people who are already stretched. Technical plans fail quietly when trust fails first.

1. Is there a single accountable delivery lead for the integration? Critical
2. Is there a plan for knowledge transfer from staff whose roles are ending, including incentives to stay through handover? Critical
3. Is there a named leader with the authority to push back on leadership timelines when the team is at capacity? High
4. Has workload on acquired and integration teams been measured against real capacity, including a realistic ramp for new members? High
5. Are key acquired engineers retained through at least the TSA exit? High
6. Are handoffs between teams, time zones or vendors defined and measured? High
7. Are role decisions communicated early and consistently, so people aren't left guessing during cutover? Moderate
8. Are milestones tied to business outcomes, with a fixed-scope, time-boxed first phase so progress is visible early? Moderate

How Sparq addresses each domain

The checklist above applies to any acquirer, with any delivery partner. This section describes how Sparq works on each domain.

• Domain 1, Application portfolio: Blueprint.IQ, Sparq's agentic codebase assessment, scans repositories for critical CVEs, committed secrets and end-of-life frameworks. It runs in an isolated environment with no code modifications and nothing touching production, and a typical engagement returns a dossier in about five days with 70 to 100 prioritized findings and a phased modernization roadmap.
• Domain 2, Data governance: Ask.IQ applies consistent semantic definitions, governance rules and access controls, so the same question gets the same answer across teams, with source-linked, auditable responses. For organizations on Snowflake, Ask.IQ Cortex runs inside the customer's own environment, so data never leaves it.
• Domain 3, TSA compliance: In one post-acquisition engagement, Sparq supported a $5B organization through a $1.3B acquisition with strict transition-service requirements and cross-selling deadlines, resulting in 100% TSA execution. Read the full write-up: "When the Deal Closes, the Data Problem Starts."
• Domain 4, Operational continuity: In The Shop, Sparq tests work inside real systems under load before it reaches a client environment, mapping failure modes and defining guardrails. Only work that holds within tolerance moves into client delivery.
• Domain 5, People and execution: Sparq assigns a US-based senior delivery lead who is accountable for the integration end to end and leads with empathy and a sense of responsibility in a stressful environment. That means acknowledging what acquired teams are going through, protecting overloaded people, planning knowledge transfer before roles end, and pushing back on timelines that put delivery at risk. Senior engineers do the hard architecture work, and the first phase is a fixed-scope, 90-day production project so progress is visible early.

First 30 days: three assessments before any modernization decision

1. Application and dependency assessment. Inventory, dependency map, secrets and CVE scan. Output: a ranked list of what is safe to leave alone, what must move first, and what can retire.
2. Data and access assessment. Systems of record, schema conflicts, access review, regulated data. Output: a governed data picture and the first reconciliation decisions.
3. TSA and continuity assessment. Service-by-service exit plan, cutover rehearsal schedule, knowledge-risk list. Output: a dated exit plan with owners.

Only after these three should you decide what to modernize, in what order, and what to run as a 90-day production project.