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
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.
We Value Your Privacy
We use cookies to enhance your experience and for traffic analysis. By continuing to visit this site you agree to our use of cookies.