Data Archival & Integration Cutover During ERP Migration

TL;DR

• Bottom line: Separate data into migrate (active master + open transactions), archive (historical for compliance), and abandon (obsolete/duplicate) categories before cutover. Switch integrations using a middleware abstraction layer during a planned cutover window, with 2-3 dress rehearsals executed beforehand.
• Key limit: Cutover window is typically 24-72 hours. Every migration task, integration switch, and validation must fit within this window or be pre-staged.
• Watch out for: Migrating all historical data into the new ERP — this inflates cutover time, degrades new system performance, and typically wastes 60-70% of migration effort on data that will never be accessed.
• Best for: Any ERP-to-ERP migration (SAP to S/4HANA, legacy to D365, NetSuite greenfield) where integrations must switch over without extended downtime.
• Authentication: Each integration must be re-authenticated against the new ERP's API surface — pre-provision service accounts, API keys, and OAuth apps weeks before cutover.

System Profile

This card covers the architecture pattern for data archival decisions and integration cutover mechanics during ERP migration. It is system-agnostic at the pattern level but includes specific tooling references for SAP, Microsoft Dynamics 365, Oracle ERP Cloud, and NetSuite. The card does NOT cover ongoing data synchronization between two live ERPs, master data governance strategy, or specific ERP API capabilities.

API Surfaces & Capabilities

Migration tools use different API surfaces than production integrations. Understanding which surface to use for each phase prevents bottlenecks.

Rate Limits & Quotas

Migration Tool Limits

Cutover Window Time Budgets

Authentication

Pre-Cutover Credential Provisioning

Authentication Gotchas

• Credential provisioning is the most commonly missed cutover task. Start 4-6 weeks before cutover. [src3]
• OAuth scopes differ between ERP versions. Map each integration's actual API usage to the new scope model. [src2]
• Test credentials created during dress rehearsals may expire before production cutover. Regenerate production credentials separately. [src6]

Constraints

• Cutover window is finite: Most enterprises negotiate 24-72 hours. Tasks that can be pre-staged should be moved out of the cutover window entirely.
• No partial integration switching: Each integration interface must point entirely to old or new ERP. Splitting creates duplicates and conflicts.
• Rollback window closes once users transact: Every transaction in the new ERP must be manually reversed on rollback. Plan a point-of-no-return decision gate.
• Audit trail continuity is legally required: In regulated industries (SOX, GDPR, HIPAA), historical transactions must remain accessible with full audit trails.
• Parallel run doubles everything: Two systems, two sets of integrations, two reconciliation processes. Only for mission-critical financial processes.
• Migration tool limits differ from production API: SAP Migration Cockpit uses staging tables (no API rate limits), but DMF uses batch framework throttling.

Integration Pattern Decision Tree

START — ERP migration with integrations to cut over
+-- How many integrations?
|   +-- < 10 --> Direct endpoint switching (manual reconfiguration)
|   +-- 10-50 --> Middleware abstraction layer (route through iPaaS)
|   +-- > 50 --> DNS/load-balancer switching + middleware routing
+-- Cutover strategy?
|   +-- Big-bang (single weekend)
|   |   +-- All integrations switch simultaneously
|   |   +-- Requires: 2-3 dress rehearsals, detailed runbook, rollback plan
|   |   +-- Data < 50M records? --> Feasible in 48h window
|   |   +-- Data > 50M records? --> Pre-stage historical, cutover only delta
|   +-- Phased (module-by-module or location-by-location)
|   |   +-- Integrations switch per module/location
|   |   +-- Requires: cross-system bridge for modules in different ERPs
|   |   +-- Budget 3-6 months total migration timeline
|   +-- Parallel run (both systems live)
|       +-- All integrations run against BOTH systems
|       +-- Requires: 2x integration capacity, daily reconciliation
|       +-- Duration: 1-4 weeks, only for mission-critical financial
+-- Historical data?
|   +-- Active master data --> MIGRATE
|   +-- Open transactions --> MIGRATE
|   +-- Closed < retention period --> ARCHIVE
|   +-- Closed > retention period --> EVALUATE
|   +-- Obsolete/duplicates --> ABANDON
+-- Rollback plan?
    +-- Before point-of-no-return --> Restore legacy, revert integrations
    +-- After users transact --> Manual reversal (costly)
    +-- No plan? --> STOP. Do not proceed.

Quick Reference

Cutover Checklist

Data Archival Decision Matrix

Step-by-Step Integration Guide

1. Inventory all integrations and classify by criticality

Document every integration: source, target, direction, frequency, volume, and criticality (P1/P2/P3). [src3]

# integration_inventory.csv template
integration_id,name,source,target,direction,frequency,volume,protocol,criticality
INT-001,Order sync,Shopify,Legacy ERP,inbound,real-time,5000/day,REST,P1
INT-002,GL posting,Legacy ERP,Data warehouse,outbound,nightly,50000,SFTP,P2
INT-003,Inventory sync,WMS,Legacy ERP,bidirectional,15min,20000/day,SOAP,P1

Verify: wc -l integration_inventory.csv matches known integration count.

2. Classify data into migrate/archive/abandon

Run data profiling against legacy ERP to categorize every table. [src4]

-- Identify active vs historical records per entity
SELECT 'customers' AS entity, COUNT(*) AS total,
  SUM(CASE WHEN last_txn_date > DATEADD(year,-2,GETDATE()) THEN 1 ELSE 0 END) AS active,
  SUM(CASE WHEN last_txn_date <= DATEADD(year,-2,GETDATE()) THEN 1 ELSE 0 END) AS inactive
FROM customers;

Verify: Sum of migrate + archive + abandon = total legacy records per entity.

3. Set up middleware abstraction layer for integration switching

Route integrations through switchable middleware endpoints for instant cutover. [src2]

// integration-router.js — switchable routing
const ROUTES = {
  'order-sync': {
    legacy: { url: 'https://legacy-erp/api/orders', auth: 'LEGACY_CREDS' },
    new_erp: { url: 'https://new-erp/api/salesorders', auth: 'NEW_CREDS' },
    active: 'legacy',  // switch to 'new_erp' during cutover
    dual_write: false   // set true for parallel run
  }
};

async function switchIntegration(id, target) {
  ROUTES[id].active = target;
  const test = await sendTestMessage(ROUTES[id][target]);
  if (!test.ok) throw new Error(`${id} post-switch test failed`);
}

Verify: Call switchIntegration('order-sync', 'new_erp') in test → confirm test message reaches new ERP.

4. Execute dress rehearsal (2-3 times before production)

Simulate the entire cutover weekend. Time every step against the window. [src1, src3]

#!/bin/bash
# dress-rehearsal.sh — Full cutover simulation
LOG="cutover_rehearsal_$(date +%Y%m%d).log"
echo "=== REHEARSAL START: $(date) ===" | tee -a "$LOG"
# Phase 1: Freeze legacy | Phase 2: Extract delta
# Phase 3: Load delta    | Phase 4: Switch integrations
# Phase 5: Validate + reconcile
echo "=== REHEARSAL END: $(date) ===" | tee -a "$LOG"
# Target: total duration fits window with 25% buffer

Verify: Total duration fits cutover window. If not, identify bottlenecks and optimize.

5. Execute production cutover and validate

Follow rehearsed runbook exactly. Run post-cutover reconciliation. [src1, src5]

# Post-cutover reconciliation
def reconcile(legacy_conn, new_conn, entities):
    for entity in entities:
        legacy_count = query_count(legacy_conn, entity['legacy_table'])
        new_count = query_count(new_conn, entity['new_table'])
        diff = abs(legacy_count - new_count)
        status = 'PASS' if diff <= entity.get('tolerance', 0) else 'FAIL'
        print(f"{entity['name']}: legacy={legacy_count} new={new_count} {status}")
    # Financial: trial balance must match to the penny

Verify: All entities PASS. Any FAIL triggers investigation before go/no-go.

Code Examples

Python: Integration Endpoint Switcher with Health Check

# Input:  Integration inventory, new ERP endpoint config
# Output: Switch confirmation with health check per integration

import httpx, asyncio

async def switch_and_verify(config, client):
    health = await client.get(f"{config.new_url}/health", headers=config.auth, timeout=10)
    if health.status_code >= 400:
        return {'id': config.id, 'status': 'BLOCKED', 'reason': f'Health: {health.status_code}'}
    await update_route(config.id, config.new_url)
    test = await client.post(f"{config.new_url}/api/test", headers=config.auth,
                             json={'cutover_test': True}, timeout=15)
    if test.status_code >= 400:
        await update_route(config.id, config.legacy_url)  # rollback
        return {'id': config.id, 'status': 'ROLLED_BACK'}
    return {'id': config.id, 'status': 'SWITCHED'}

SQL: Data Archival Pre-Migration Manifest

-- Generate archival manifest showing migrate/archive/abandon volumes
WITH data_age AS (
  SELECT 'invoices' AS entity, COUNT(*) AS total,
    SUM(CASE WHEN status='OPEN' THEN 1 ELSE 0 END) AS migrate,
    SUM(CASE WHEN status='CLOSED' AND dt > DATEADD(year,-7,GETDATE()) THEN 1 ELSE 0 END) AS archive,
    SUM(CASE WHEN status='CLOSED' AND dt <= DATEADD(year,-7,GETDATE()) THEN 1 ELSE 0 END) AS abandon
  FROM invoices
)
SELECT entity, total, migrate, archive, abandon,
  ROUND(100.0*(archive+abandon)/NULLIF(total,0),1) AS pct_not_migrated
FROM data_age;
-- Expected: 60-80% not migrated = faster cutover

Bash: SAP Migration Cockpit Delta Load

# Upload delta to Migration Cockpit staging tables
curl -X POST "https://s4hana.company.com/sap/opu/odata/sap/API_MIG_OBJ_STAGING_SRV/StagingFiles" \
  -H "Authorization: Bearer $SAP_TOKEN" -H "x-csrf-token: $CSRF_TOKEN" \
  -H "Content-Type: application/octet-stream" -H "slug: CUSTOMER_DELTA.xml" \
  --data-binary @customer_delta.xml

# Trigger migration run (SIMULATE first, then MIGRATE)
curl -X POST "https://s4hana.company.com/sap/opu/odata/sap/API_MIG_OBJ_STAGING_SRV/MigrationRuns" \
  -H "Authorization: Bearer $SAP_TOKEN" -H "x-csrf-token: $CSRF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"MigrationObject":"CUSTOMER","RunMode":"SIMULATE"}'

Data Mapping

Cutover Data Flow Mapping

Data Type Gotchas

• COA restructuring: New COA structure requires re-mapping every historical transaction. Define mapping before archival. [src4]
• Currency precision: Legacy 2-decimal vs SAP 3+ decimals — rounding differences cause reconciliation failures. [src6]
• Timezone during cutover: Transactions near cutover timestamp may show incorrect dates if legacy/new handle UTC differently. [src1]
• Document number gaps: New ERP starts different sequence. Integrations referencing legacy doc numbers need cross-reference lookup. [src3]

Error Handling & Failure Points

Common Cutover Errors

Failure Points in Production

• Delta data loss during freeze: Transactions between last extract and freeze are lost. Fix: Tight freeze-extract-validate loop before proceeding. [src1]
• Integration switch-back fails on rollback: Messages queued during cutover are lost. Fix: Queue all messages in middleware DLQ during cutover; replay on rollback. [src2]
• Rehearsal timing does not match production: Production has more data and concurrent activity. Fix: Use full production-volume data in dress rehearsals. [src3]
• Archived data inaccessible after decommission: Archive in legacy format without query interface. Fix: Deploy read-only archival system before decommissioning. [src4]
• Audit trail broken at cutover boundary: Cannot trace legacy to new. Fix: Maintain cross-reference table (legacy_doc_id to new_doc_id) in archival. [src4]
• Parallel run reconciliation overwhelms team: Hundreds of timing discrepancies daily. Fix: Define tolerance bands; auto-dismiss timing diffs < 24h. [src5]

Anti-Patterns

Wrong: Migrating all historical data into the new ERP

// BAD — migrating 10+ years of closed transactions
MIGRATE: ALL invoices 2010-2025 (5,000,000)   // 80% closed, never accessed
MIGRATE: ALL POs 2010-2025 (3,000,000)        // 75% closed, never accessed
MIGRATE: ALL journal entries (20,000,000)      // historical, not operational
// Result: 96h cutover, degraded performance, $500K+ effort

Correct: Archive historical, migrate only active + open

// GOOD — archive first, migrate lean
MIGRATE: Active masters (50K) + Open transactions (23K)
MIGRATE: Trial balance as opening journal (1 entry per GL account)
ARCHIVE: Closed 2019-2025 to data warehouse
ABANDON: Pre-2019 closed + duplicates (after legal review)
// Result: 36h cutover, optimal performance, 6 weeks effort

Wrong: No parallel run for financial integrations

// BAD — switch GL integration without verification
Friday 8PM: Switch GL posting to new ERP
Monday 8AM: Finance discovers GL out of balance by $2.3M
// Root cause: currency conversion logic different in new ERP
// No reconciliation, no parallel run, no smoke test

Correct: Parallel run financial integrations with daily reconciliation

// GOOD — parallel run GL for 1-2 weeks
Week 1: GL posts to BOTH legacy and new ERP
        Daily reconciliation: compare per GL account
Week 2: Discrepancies < 0.01% for 3 consecutive days
        Deactivate legacy, new ERP is sole system of record
// Cost: 2 weeks dual effort. Benefit: $0 in restatements

Wrong: Switching integrations without middleware abstraction

// BAD — reconfiguring each source system individually
Hour 1: SSH into Shopify app, change endpoint, restart
Hour 2: SSH into WMS, update config file, restart
Hour 3: Log into Salesforce, update named credential
Hour 12: Discover WMS config typo — 8 hours of data lost

Correct: Route through middleware with single-point switching

// GOOD — middleware handles routing; source systems unchanged
Pre-cutover: All integrations route through iPaaS to legacy
Cutover: Change iPaaS target config per integration (< 1 min each)
         Each switch includes automated health check
Rollback: Change config back (< 1 min per integration)
// Source systems never change. Rollback is instant.

Common Pitfalls

• Skipping dress rehearsals: First rehearsal finds gaps, second tests fixes, third validates timing. Fix: Mandate 2-3 full rehearsals in production-equivalent environment. [src1]
• Underestimating delta volume: 2-week gap between pre-load and freeze can produce 100K+ new transactions. Fix: Run pre-loads close to cutover; calculate expected delta from daily rates. [src1]
• Timezone confusion during cutover: Multi-timezone teams report timestamps inconsistently. Fix: Use UTC for all cutover timestamps and log entries. [src3]
• No defined point-of-no-return: No framework for rollback vs fix-forward decision Monday morning. Fix: Define rollback criteria before cutover; decision gate at T+24h. [src5]
• Legacy decommissioned before archival verified: IT saves hosting costs, finance discovers they need 2019 tax records. Fix: Do not decommission until archival access verified; 90-day minimum verification. [src4]
• Sequence number gaps: New ERP numbering confuses downstream EDI partners. Fix: Start new sequences above legacy max + buffer. [src6]
• Integration message ordering during cutover: Queued messages arrive out of order at new ERP. Fix: FIFO queues or handle out-of-order via timestamps. [src2]
• Testing integrations individually but not end-to-end: Each passes smoke test, but order-to-cash flow fails due to mapping inconsistencies. Fix: Run end-to-end business process tests during rehearsal. [src3]

Diagnostic Commands

# Compare record counts: legacy vs new ERP (post-cutover)
psql -h legacy-erp -d erp -c "SELECT 'customers', COUNT(*) FROM customers WHERE status='ACTIVE'" \
  && psql -h new-erp -d erp -c "SELECT 'customers', COUNT(*) FROM bp_master WHERE status='ACTIVE'"

# Check D365 DMF import job status
curl -s "https://d365.operations.dynamics.com/data/DataManagementJobs" \
  -H "Authorization: Bearer $D365_TOKEN" | jq '.value[] | {jobId:.JobId, status:.Status}'

# Check SAP Migration Cockpit errors
curl -s "https://s4hana.company.com/sap/opu/odata/sap/API_MIG_OBJ_STAGING_SRV/MigrationRuns?\$filter=RunStatus eq 'ERROR'" \
  -H "Authorization: Bearer $SAP_TOKEN" | jq '.d.results[]'

# Validate trial balance match
psql -h legacy -c "SELECT SUM(debit), SUM(credit) FROM gl_entries WHERE period <= '2026-03'" \
  && psql -h new-erp -c "SELECT SUM(debit), SUM(credit) FROM gl_journal WHERE type='OPENING'"

Version History & Compatibility

When to Use / When Not to Use

Cross-System Comparison

Migration Tool Comparison

Important Caveats

• This card describes patterns, not product-specific procedures. Use for strategy, then consult vendor docs for implementation.
• Cutover timing is business-dependent: retail may need January, manufacturing may need plant shutdown periods, 24/7 operations may have no acceptable window.
• Regulatory requirements vary: SOX (7 years financial), GDPR (deletion capability), HIPAA (health data controls). Consult legal/compliance before defining archival scope.
• Migration consulting costs ($150-500K for mid-size, $1M+ for multi-country) are separate from ERP licensing.
• Parallel run is the gold standard but often infeasible — 2x effort is only justified for mission-critical financial processes.
• This card reflects tooling current as of March 2026. Migration tools update with each ERP release cycle.