How do you migrate off a system with no API?

An API is convenient, not essential

Migration is a bounded transfer of state, not necessarily a permanent integration. Many legacy systems expose useful data through reports, scheduled files, backup formats or direct database access even when they have no service API. The first task is to inventory these surfaces with the system owner and vendor. Supported exports are preferable because their semantics are documented. Read-only database extraction can be complete but requires schema interpretation. Screen automation is fragile and slow, and belongs at the end of the options list rather than the beginning.

Before extraction, define what must move and why. Active master data, open transactions, balances, attachments and audit history have different target uses. Some history may remain in a searchable, read-only archive if operational and retention needs permit. That is a design decision, not discarded scope. For each population, specify cut-off date, owner, target representation and reconciliation rule. A field mapping that says customer_id to customer_id is inadequate if identifiers have been merged, reused or scoped differently across branches.

Profile the source before designing transforms

Inspect actual values, null patterns, duplicates, ranges, encodings and referential gaps. Legacy applications often enforce rules in interface code rather than the database, so apparently simple tables may contain states no current screen can create. Reports may apply hidden filters or calculate balances dynamically. Compare extracts with visible records and control reports to establish population completeness. Preserve raw extracts immutably with acquisition time, source version and checksums, subject to security policy. Repeatable transformation can then be corrected without repeatedly touching a fragile production source.

• Prefer documented exports, then read-only database or backup extraction.
• Capture raw source data before cleansing and retain lineage to target records.
• Reconcile counts, control totals, balances and sampled business events.
• Test attachments, encodings, time zones and identifiers explicitly.
• Rehearse cut-over using the intended extraction sequence and access accounts.

Meaning is reconstructed from several sources

Schema names alone rarely explain the domain. Combine database constraints, application labels, reports, user procedures and representative transaction traces. Where interpretation remains uncertain, record the decision and obtain accountable business approval. Transformations should be versioned code with automated checks, not a chain of manually edited spreadsheets. Rejected records need explicit reasons and an owner; silently defaulting an unknown status manufactures data. Where target rules are stricter, cleansing can occur at source, in a governed staging area or through approved target exceptions, but the chosen path must remain auditable.

Reconcile at business boundaries

Row counts prove little when one source row becomes several target records or duplicates are deliberately merged. Reconciliation should use control totals and domain populations: open receivables by currency, inventory quantity and value by location, active contracts by state, or orders by fulfilment stage. Trace sampled records end to end, including corrections and attachments. Finance migrations require a bridge from source trial balance to opening entries and open-item detail. Every unexplained difference should be resolved or formally accepted before go-live, with reports retained as cut-over evidence.

Control coexistence and cut-over

If both systems operate during transition, define which one accepts changes for each record and how updates cross the boundary. Informal dual entry creates conflicting truth. A freeze window simplifies migration but may be operationally impossible; a delta extraction can capture changes since the full rehearsal if timestamps and deletion markers are trustworthy. The cut-over runbook should name commands, timings, approvals, validation gates and rollback conditions. Rehearsal establishes whether the window is feasible and exposes vendor access, storage and performance constraints before the final event.

Retire the old system deliberately

Decommissioning follows confirmation that the target operates correctly and retained history is accessible. Archive data in documented, durable formats with a data dictionary and a controlled query route. Preserve evidence needed for legal, tax, audit or contractual retention while deleting data that no longer has a lawful purpose. Remove integrations and credentials, terminate licences according to contract, and record the final backup and access owners. A virtual machine image without documented dependencies is not a reliable archive; future access must be tested independently of obsolete infrastructure.