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) 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.

Template metadata
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

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
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.

Marketplace