---
title: "Data Migration Plan and Customer Data Readiness Checklist (IDK-15)"
date: 2026-09-21
description: "Ready-to-use template IDK-15: Data Migration Plan and Customer Data Readiness Checklist for IFS Cloud, aligned with the IFS implementation methodology."
author: "Dariusz Mysliwiec"
categories:
  - name: "Implementation docs kit"
    url: "https://www.ifs-erp.com/implementation-docs-kit.md"
---

# Data Migration Plan and Customer Data Readiness Checklist (IDK-15)

Template IDK-15, version 1.0. Phase: Confirm Prototype (plan established), maintained through Establish Solution and Implement Solution.

 ## How to use this template

 
- This plan puts the data migration strategy (template [IDK-14](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/14-data-migration-strategy)) into practice. It lists every data object with its source, owner, method, load order and sign-off.
- Part A is the customer data readiness checklist. It needs no IFS Cloud environment. Start it on the day the project is approved.
- Part B is the plan per data object. It is split into three tables that share the same ID. In a spreadsheet they can be one wide table.
- Update the plan after every load cycle. The version at the end of the rehearsal feeds the hour-by-hour cutover checklist.
- Replace every `[...]` field. Delete the rows marked `Example:` once your own rows exist.

 | Field | Value |
| --- | --- |
| Template ID | IDK-15 |
| Phase | Confirm Prototype (plan established), maintained through Establish Solution and Implement Solution |
| Owner | Customer data migration lead, supported by the data migration consultant |
| Approver | Customer project manager, with sign-off per data object by the business data owner |
| Qualification gate | Solution Confirmed |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [A1. Inventory of sources](#a1-inventory-of-sources)
- [A2. Numbering schemes](#a2-numbering-schemes)
- [A3. Duplicates and conflicts](#a3-duplicates-and-conflicts)
- [A4. Active-only and history decisions](#a4-active-only-and-history-decisions)
- [A5. Units of measure](#a5-units-of-measure)
- [A6. Reference values](#a6-reference-values)
- [A7. Structured fields](#a7-structured-fields)
- [A8. Mandatory classifications](#a8-mandatory-classifications)
- [A9. Readiness summary](#a9-readiness-summary)
- [B1. Plan part 1: object, source and method](#b1-plan-part-1-object-source-and-method)
- [B2. Plan part 2: dependencies, load order and mapping](#b2-plan-part-2-dependencies-load-order-and-mapping)
- [B3. Cleansing tasks](#b3-cleansing-tasks)
- [B4. Plan part 3: load cycles, validation and sign-off](#b4-plan-part-3-load-cycles-validation-and-sign-off)
- [B5. Cycle calendar](#b5-cycle-calendar)
- [B6. Issues and decisions from load cycles](#b6-issues-and-decisions-from-load-cycles)
- [B7. Handling of extract files](#b7-handling-of-extract-files)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Plan owner | [Name, role] |
| Data migration consultant (supplier) | [Name] |
| Strategy reference | [Link to the approved data migration strategy, version] |
| Status | [Draft / Established / Updated after cycle n / Final for cutover] |
| Storage location | [Link] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | Readiness checklist started |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change, for example "updated after load cycle n"] |

 Work through this per data group: parts, suppliers, customers, prices, structures, open transactions. Record findings, not just ticks. Every finding becomes a cleansing task in section B3.

 ## A1. Inventory of sources

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Every system, database, spreadsheet and paper file that holds data of this group is listed | Example: Supplier data sits in the legacy ERP, in a purchasing spreadsheet with contacts and in the accounts payable tool with bank details | [Name] | [ ] |
| For each source: who maintains it, how current it is, how it can be extracted | [Finding] | [Name] | [ ] |
| Where two sources hold the same record, the leading source is decided | [Finding] | [Name] | [ ] |
| Data held only in people's heads or mailboxes is identified | [Finding] | [Name] | [ ] |

 ## A2. Numbering schemes

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Current numbering logic is documented per object | Example: Part numbers carry the product family in the first characters. Newer parts no longer follow that rule. | [Name] | [ ] |
| Decision made: keep numbers or renumber | [Decision and reasoning] | [Name] | [ ] |
| If renumbering: cross-reference list is kept, and where users will find the old number | [Finding] | [Name] | [ ] |
| Numbers with meaning built in are reviewed. Classification fields do that job better. | [Finding] | [Name] | [ ] |
| Characters, length and leading zeros are checked against what the target fields accept | [Finding] | [Name] | [ ] |

 ## A3. Duplicates and conflicts

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Duplicate records are identified, within one source and across sources | Example: Same supplier created once per site, with different payment terms | [Name] | [ ] |
| Surviving record is chosen per duplicate set, and conflicting values are resolved by the owner | [Finding] | [Name] | [ ] |
| Open transactions on records that will be merged are listed | [Finding] | [Name] | [ ] |

 ## A4. Active-only and history decisions

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Rule for "active" is defined per object, in line with the strategy | Example: Parts with stock, open orders or movement since `[agree in project]` | [Name] | [ ] |
| Records outside the rule that the owner still wants are nominated by name, with a reason | [Finding] | [Name] | [ ] |
| Records to be left behind are marked in the source so extracts can exclude them | [Finding] | [Name] | [ ] |
| Unused fields are identified and dropped from the extract | [Finding] | [Name] | [ ] |

 ## A5. Units of measure

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| All units in use are listed, with spelling variants of the same unit | Example: "PCS", "pc", "each" and "EA" all mean one piece | [Name] | [ ] |
| One target unit list is agreed | [Finding] | [Name] | [ ] |
| Parts bought, stocked and sold in different units have verified conversion factors | [Finding] | [Name] | [ ] |
| Parts whose stocking unit should change are decided before balances are extracted | [Finding] | [Name] | [ ] |

 ## A6. Reference values

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Countries, currencies and languages use standard codes | Example: Country entered as free text in several spellings | [Name] | [ ] |
| Payment terms, delivery terms and ship-via values are rationalised to the list agreed in the Book of Rules | [Finding] | [Name] | [ ] |
| Groups and categories that nobody reports on are retired | [Finding] | [Name] | [ ] |
| A translation table from legacy value to target value exists per reference field | [Finding] | [Name] | [ ] |

 ## A7. Structured fields

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Addresses are split into the correct fields. Postcodes follow the country format. | [Finding] | [Name] | [ ] |
| Tax numbers, bank details, phone numbers and e-mail addresses are in valid formats | [Finding] | [Name] | [ ] |
| Information held in free-text notes that the new process needs as a field is identified and moved | Example: "Certificate required" written in the part note | [Name] | [ ] |
| Free-text notes that will not be migrated are agreed with the owner | [Finding] | [Name] | [ ] |

 ## A8. Mandatory classifications

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Classifications the new processes depend on are listed from the Book of Rules | Example: Every purchased part needs a purchase part group, a planner and a primary supplier | [Name] | [ ] |
| Completeness is measured per classification in the legacy data | [Finding] | [Name] | [ ] |
| Missing values are assigned to owners to complete, at source where possible | [Finding] | [Name] | [ ] |
| Default values are avoided. A default hides a decision nobody made. | [Finding] | [Name] | [ ] |

 ## A9. Readiness summary

 | Data group | Owner | Sources known | Duplicates resolved | Active rule applied | Units and references clean | Classifications complete | Ready for first load |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: Suppliers | Purchasing manager | Yes | In progress | Yes | Yes | In progress | No |
| [Group] | [Name] | [Status] | [Status] | [Status] | [Status] | [Status] | [Yes / No] |

 ## B1. Plan part 1: object, source and method

 Method values: Migration job / Copy and paste or file import on a standard page / Manual entry / Configuration package.

 | ID | Data object | Scope rule | Source system and extract | Business owner | Technical owner | Method | Reason for method |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: DM-010 | Inventory parts | Active per rule in A4 | [Legacy ERP], extract [name] | Warehouse manager | [Name] | Migration job | Large set, loaded in every cycle |
| Example: DM-004 | Units of measure | Target list from A5 | Book of Rules | Warehouse manager | [Name] | Manual entry | Small set, entered once, then moved as configuration |
| Example: DM-030 | Open purchase order lines | Open quantity at cutover | [Legacy ERP], extract [name] | Purchasing manager | [Name] | Migration job | Volume, and must reconcile to legacy |
| [ID] | [Object] | [Rule] | [Source] | [Name] | [Name] | [Method] | [Reason] |

 ## B2. Plan part 2: dependencies, load order and mapping

 The load order follows the dependencies in the application: basic data before master data, master data before transactions.

 | ID | Load sequence | Depends on | Target (entity or page) | Mapping status | Mapping document | Open mapping questions |
| --- | --- | --- | --- | --- | --- | --- |
| Example: DM-010 | [n] | Units of measure, part groups, sites | Inventory part | Approved by owner [YYYY-MM-DD] | [Link] | None |
| Example: DM-030 | [n] | Suppliers, purchase parts, supplier for purchase part, sites | Purchase order and lines | Draft | [Link] | How are partly received lines loaded: open quantity only, or full line with receipt? |
| [ID] | [n] | [IDs or objects] | [Target] | [Not started / Draft / Approved] | [Link] | [Questions] |

 ## B3. Cleansing tasks

 | Task ID | Data object | Task | Where it is done | Owner | Due | Status | Measure of progress |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: CL-007 | Suppliers | Merge site-specific duplicates, agree one set of payment terms per supplier | Legacy ERP | Purchasing manager | [YYYY-MM-DD] | In progress | Duplicate sets remaining: [count] |
| [ID] | [Object] | [Task] | [Source system / Transformation step] | [Name] | [YYYY-MM-DD] | [Status] | [Measure] |

 ## B4. Plan part 3: load cycles, validation and sign-off

 Number of load cycles: `[agree in project]`. Add or remove cycle columns to match.

 | ID | Cycle 1 result | Cycle 2 result | Cycle [n] result | Rehearsal result and duration | Validation query or check | Reconciliation figure | Sign-off by owner, date |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: DM-010 | Sample loaded. Rejections: missing planner on [count] parts. | Full extract loaded. Rejections assigned as CL-012. |   | [Duration from log] | Count of parts per site and part status equals extract. Owner samples records field by field. A migrated part can be purchased and received. | Record count | [Name], [YYYY-MM-DD] |
| Example: DM-030 | Not in cycle | Full extract loaded |   | [Duration from log] | Open lines and open quantity per site and supplier equal the legacy open order report at the same cut-off | Line count, open quantity |   |
| [ID] | [Result] | [Result] | [Result] | [Result] | [Check] | [Figure] | [Name, date] |

 Per cycle, record for each object: records in extract, records loaded, records rejected, reasons, and the owner of each correction.

 ## B5. Cycle calendar

 | Cycle | Purpose | Environment | Extract date | Load window | Validation window | Objects included | Exit review |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: Cycle 1 | Prove jobs and load order with sample data | [Environment] | [YYYY-MM-DD] | [Dates] | [Dates] | Basic data, parts, suppliers | [Date, attendees] |
| [Cycle] | [Purpose] | [Environment] | [YYYY-MM-DD] | [Dates] | [Dates] | [Objects] | [YYYY-MM-DD] |
| Verification cycle before SAT | Processes run with real security and migrated data | [Environment] | [YYYY-MM-DD] | [Dates] | [Dates] | All | [YYYY-MM-DD] |
| Rehearsal | Full volumes, timings logged, plan corrected | [Environment] | [YYYY-MM-DD] | [Dates] | [Dates] | All | [YYYY-MM-DD] |
| Cutover | Production load | Production | [YYYY-MM-DD] | Per cutover checklist | Per cutover checklist | All | Release decision |

 ## B6. Issues and decisions from load cycles

 | ID | Cycle | Data object | Issue | Cause (data, mapping, job, solution) | Owner | Action | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [Cycle] | [Object] | [Issue] | [Cause] | [Name] | [Action] | [Open / Closed] |

 ## B7. Handling of extract files

 Follow the rules in the strategy. Record here where each cycle's files are stored and when they were deleted.

 | Cycle | Storage location | Access limited to | Deleted on, by |
| --- | --- | --- | --- |
| [Cycle] | [Location] | [Roles] | [Date, name] |

 ## Approval

 Approval at the Solution Confirmed gate states that the plan is established: source data is identified, cleansing is under way with named owners, and a method is chosen for every data object. Sign-off per object happens in table B4.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer data migration lead | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [Name] |   |   |   |
| Data migration consultant (reviewed) | [Name] |   |   |   |
| Supplier project manager | [Name] |   |   |   |

 Final data sign-off at cutover:

 | Data group | Business owner | Reconciliation reference | Date | Signature |
| --- | --- | --- | --- | --- |
| [Group] | [Name] | [Link] | [YYYY-MM-DD] |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.