# Data Migration > Use when planning, designing, or executing SAP data migration. Triggers on requests involving data migration strategy, data mapping, LTMC, BODS, legacy data conversion, reconciliation, trial migration, or cutover data load. - **Type:** Skill - **Install:** `agentstack add skill-vigneshbarani24-sap-superpowers-data-migration` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [vigneshbarani24](https://agentstack.voostack.com/s/vigneshbarani24) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [vigneshbarani24](https://github.com/vigneshbarani24) - **Source:** https://github.com/vigneshbarani24/sap-superpowers/tree/main/skills/delivery/data-migration - **Website:** https://sap-superpowers.vercel.app/ ## Install ```sh agentstack add skill-vigneshbarani24-sap-superpowers-data-migration ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # SAP Data Migration This skill enforces structured, evidence-based data migration — preventing the three most common catastrophic failures: migrating without reconciliation, skipping data profiling, and assuming source data is clean. --- ## Iron Laws 1. **NEVER MIGRATE WITHOUT RECONCILIATION.** Every migrated object must be counted and reconciled: records sent = records loaded = records validated. A migration without reconciliation is a migration with unknown quality. 2. **NEVER SKIP DATA PROFILING.** You cannot map what you haven't profiled. Data profiling is not optional prep — it is the foundation everything else is built on. 3. **NEVER ASSUME SOURCE DATA IS CLEAN.** Source data is always dirty. The question is how dirty. Data profiling quantifies the dirt. Remediation cleans it. Assuming it's clean skips both steps. 4. **ALWAYS RUN AT LEAST ONE TRIAL MIGRATION.** A trial migration in a non-production system is non-negotiable. The first full load CANNOT be the production cutover load. 5. **TRANSFORMATION RULES ARE DOCUMENTED BEFORE LOAD, NOT AFTER.** If a transformation rule is not in the mapping document before loading, it does not exist. Post-hoc documentation of "what we actually did" is not a migration document. --- ## Rationalization Table | Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter | |---|---|---|---| | Skip data profiling to save time | "We know the source system well" | Knowing the system ≠ knowing its data quality. Legacy data accumulated over years has integrity issues the source team doesn't know about. | Iron Law 2: Profiling is non-negotiable. At minimum: record counts, null rates, format violations, referential integrity checks. | | Declare migration complete without reconciliation | "Everything loaded without errors" | Error-free load ≠ complete load. Records can be silently skipped, truncated, or misrouted. Only counts prove completeness. | Iron Law 1: Reconciliation report required. Records out = records in, or explain every delta. | | Use big bang strategy without considering phased option | "It's simpler to do everything at once" | Big bang increases cutover window, risk of failure, and rollback complexity. Phased migration is often safer. Justify the choice with evidence. | Checklist Step 1: Strategy decision documented with justification and risk assessment. | | Assume vendor/partner master data is correct | "The client maintains this data themselves" | Client-maintained data has format issues, duplicates, and gaps. Profile it the same way as any other source. | Iron Law 3: Profile all sources without exception. | | Skip trial migration because "dev loads worked" | "We've done partial loads in dev" | Partial dev loads ≠ full trial migration. Trial migration tests volume, performance, error handling, and reconciliation in an integrated environment. | Iron Law 4: Full trial migration mandatory. Dev loads do not satisfy this requirement. | | Defer cleansing to post-migration | "We'll clean it up once it's in SAP" | SAP has strict validation rules. Dirty data that loads creates more remediation effort in SAP than in the source. Clean before migration. | Checklist Step 3: Cleansing rules and completion criteria defined and executed before load. | --- ## Red Flags Watch for these phrases in your own reasoning — each signals an Iron Law violation: - "The source data looks pretty good..." → You haven't profiled it. Stop. - "We can reconcile after go-live..." → Post-go-live reconciliation of migrated data is triage, not validation. Stop. - "The load ran without errors, so it's complete..." → Error-free ≠ complete. Run reconciliation. Stop. - "We did this for the dev load, we don't need a trial migration..." → Dev load ≠ trial migration. Stop. - "The transformation is simple enough to document later..." → Iron Law 5. Document first. Stop. - "The client assured us the data is clean..." → Client assurance is not a data profile. Stop. - "We'll do big bang, it's just easier..." → Justify the risk with evidence. Stop. --- Trial migration CANNOT be skipped. Production cutover data load cannot proceed until: 1. Data profiling is complete and results documented for ALL objects in scope 2. Data cleansing rules are defined, executed, and sign-off obtained from the business 3. Full field-level mapping document is approved — source field → transformation rule → target SAP field 4. At least one full trial migration has been executed in a non-production environment 5. Trial migration reconciliation report confirms record counts match within defined tolerance 6. Data migration test sign-off obtained from business data owners If any condition is unmet, the production load is NOT authorized. Do not proceed. --- ## Checklist 1. **Define migration strategy** — Choose and justify big bang vs. phased migration. Document scope: which objects, which legacy systems, cutover timeline. - Evidence: Migration strategy document with approach, justification, object scope, and phasing plan - Gate: Strategy reviewed and approved by project manager and client data owner 2. **Execute data profiling** — For every migration object, profile the source data: record counts, null rates, format compliance, duplicates, referential integrity, business rule violations. - Evidence: Data profiling report per object with quantified quality metrics - Gate: Profiling complete for 100% of in-scope objects; results reviewed by business owner 3. **Define cleansing rules and execute cleansing** — Based on profiling results, define transformation and cleansing rules. Execute cleansing in source or staging area. Measure improvement. - Evidence: Cleansing rules document; before/after data quality metrics; business sign-off on cleansed data - Gate: Cleansed data meets defined quality thresholds; business owner signs off 4. **Build field-level mapping document** — For every source field in scope, document: source system, field name, transformation logic, target SAP object, target field, mandatory/optional, validation rule. - Evidence: Data mapping document approved by functional consultants and business - Gate: Mapping reviewed by SAP functional lead; no unmapped mandatory SAP fields 5. **Configure migration tooling** — Set up LTMC, BODS, or custom migration program. Validate tool configuration matches the mapping document. - Evidence: Migration program / LTMC project configured; test load of sample records confirms correct field mapping - Gate: Sample load of 10–50 records validates all transformations correctly 6. **Execute trial migration** — Run full migration load for all objects in a non-production environment. Do not skip objects or volumes. - Evidence: Trial migration execution log; record counts per object (source vs. loaded) - Gate: Load completes without critical errors; record counts within tolerance 7. **Reconcile trial migration** — Compare source record counts to loaded SAP counts. Investigate all discrepancies. Document resolution for each delta. - Evidence: Reconciliation report: source count, load count, delta, resolution per object - Gate: All deltas explained and resolved or formally accepted; zero unexplained discrepancies 8. **Obtain data migration sign-off** — Present trial migration results and reconciliation to business data owners. Obtain written approval to proceed to production load. - Evidence: Signed data migration sign-off document - Gate: Sign-off obtained before production cutover window opens --- ## Deliverable Templates ### Data Migration Plan ``` PROJECT: [Name] DATE: [Date] VERSION: [Version] MIGRATION STRATEGY ------------------ Approach: [Big Bang / Phased — with justification] Legacy systems: [List source systems] Cutover window: [Date range, duration] Rollback trigger: [Conditions that trigger rollback] OBJECTS IN SCOPE ---------------- | Object | Source System | Tool | Volume (records) | Priority | Owner | |-----------------|--------------|-------|-----------------|----------|-----------| | Vendor Master | Legacy ERP | LTMC | ~12,000 | P1 | [Name] | | Customer Master | Legacy CRM | BODS | ~8,500 | P1 | [Name] | | Open Items (AP) | Legacy ERP | LTMC | ~45,000 | P1 | [Name] | | Material Master | Legacy ERP | LTMC | ~30,000 | P1 | [Name] | MIGRATION TIMELINE ------------------ Data profiling: [Start] → [End] Data cleansing: [Start] → [End] Mapping: [Start] → [End] Trial migration 1: [Date] Trial migration 2: [Date] Production load: [Date] [Time window] RECONCILIATION TOLERANCE ------------------------ Standard objects: 0% variance (exact count match required) Complex objects: Up to [X]% variance with documented justification ``` ### Data Mapping Document (per object) ``` OBJECT: [e.g., Vendor Master] SOURCE SYSTEM: [e.g., Oracle EBS] TARGET: SAP LFM1 / LFA1 MAPPING VERSION: [Version] | Source Field | Source Type | Transformation Rule | Target Table | Target Field | Mandatory | Validation | |-----------------|------------|---------------------------------------|-------------|-------------|-----------|---------------------| | VENDOR_CODE | VARCHAR(10) | Prefix with 'V', zero-pad to 10 chars | LFA1 | LIFNR | YES | Unique in LFA1 | | VENDOR_NAME | VARCHAR(80) | Trim whitespace, UPPER case | LFA1 | NAME1 | YES | Max 35 chars | | COUNTRY_CODE | VARCHAR(2) | Map legacy to ISO 3166-1 alpha-2 | LFA1 | LAND1 | YES | Valid T005 entry | | PAYMENT_TERMS | VARCHAR(10) | Map to SAP ZTERM via lookup table | LFB1 | ZTERM | YES | Valid T052 entry | ``` ### Reconciliation Report ``` TRIAL MIGRATION: [Trial # and Date] ENVIRONMENT: [System ID] | Object | Source Count | Loaded Count | Delta | Delta % | Status | Resolution | |-----------------|-------------|-------------|-------|---------|-------------|------------------------| | Vendor Master | 12,043 | 12,043 | 0 | 0.0% | PASS | — | | Customer Master | 8,521 | 8,517 | 4 | 0.05% | INVESTIGATE | 4 records missing LAND1| | Open Items (AP) | 45,230 | 45,230 | 0 | 0.0% | PASS | — | OVERALL STATUS: [PASS / FAIL / CONDITIONAL PASS] SIGN-OFF REQUIRED FROM: [Data owner names] ``` --- ## Verification This skill is complete ONLY when ALL of the following are true: - [ ] Migration strategy documented and approved (big bang vs. phased with justification) - [ ] Data profiling complete for 100% of in-scope migration objects - [ ] Cleansing rules defined and executed; business sign-off on cleansed data obtained - [ ] Full field-level mapping document approved by functional consultants - [ ] Migration tooling configured and sample load validated - [ ] At least one full trial migration executed in a non-production environment - [ ] Reconciliation report confirms zero unexplained discrepancies - [ ] Data migration sign-off obtained from business data owners in writing **Evidence required:** Data profiling report, cleansing sign-off, mapping document, trial migration execution log, reconciliation report, signed data migration sign-off. If any item is unchecked, this skill is NOT complete. Do not authorize the production data load. --- ## Next Skill After completing this skill, invoke: `cutover-planning` Conditions for handoff: Data migration trial complete and signed off. Cutover planning must sequence the production data load as a critical path task within the cutover runbook. --- ## Cross-References - `testing-strategy` — Data migration testing (trial run, reconciliation) is part of the overall test strategy - `cutover-planning` — Production data load is a key step in the cutover runbook - `go-live-readiness` — Data migration sign-off is a required input to the go/no-go matrix - `sap-data-analyst` agent — Use for automated data profiling and anomaly detection ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [vigneshbarani24](https://github.com/vigneshbarani24) - **Source:** [vigneshbarani24/sap-superpowers](https://github.com/vigneshbarani24/sap-superpowers) - **License:** MIT - **Homepage:** https://sap-superpowers.vercel.app/ Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-vigneshbarani24-sap-superpowers-data-migration - Seller: https://agentstack.voostack.com/s/vigneshbarani24 - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.