Data Migration Strategy Template (IDK-14)

Template IDK-14, version 1.0. Phase: Initiate Project.

How to use this template

Write this document in the first phase. It sets the approach and the principles. The detail per data object belongs in the data migration plan (template IDK-15), which follows in Confirm Prototype.
Its main job is to settle three arguments early: what is migrated, how much history comes along, and who owns the data. Get those decisions signed by the steering group.
Where a value is needed, such as the number of load cycles, leave [agree in project] until the project has decided. Do not copy a figure from another project.
The customer owns the data and this strategy. The supplier advises on method and tooling.
Replace every [...] field. Delete the rows marked Example: before approval.

Template metadata
Field	Value
Template ID	IDK-14
Phase	Initiate Project
Owner	Customer project manager, supported by the supplier project manager
Approver	Steering group
Qualification gate	Project Initiated
Version	1.0

Document control

Field	Value
Project	[Project name]
Document owner	[Name, role]
Data migration lead (customer)	[Name]
Data migration consultant (supplier)	[Name]
Status	[Draft / In review / Approved]
Storage location	[Link]

Version	Date	Author	Change	Approved by
0.1	[YYYY-MM-DD]	[Name]	First draft
[x.y]	[YYYY-MM-DD]	[Name]	[Change]	[Name]

1. Purpose and position in the project

This strategy states how data will move from the legacy systems into IFS Cloud, on what principles, and who is responsible. It is one of the strategy documents confirmed at the Project Initiated gate.

Phase	Data migration activity	Document
Initiate Project	Approach, principles, scope outline and responsibilities agreed	This strategy
Confirm Prototype	Every data object listed with source, owner and method. Cleansing under way.	Data migration plan (template IDK-15)
Establish Solution	Mapping, iterative loads, validation by functional teams, volume test	Plan updated per cycle, validation records
Implement Solution	Full rehearsal with complete volumes and logged timings	Cutover plan and cutover checklist
Go Live	Final extract, load, reconciliation and sign-off	Cutover checklist, reconciliation records

2. Principles

Adjust the wording. Keep the list short enough that people remember it.

The business owns the data. Each data object has a named business owner who decides what is migrated and signs off the result.
Migrate what the new processes need, not what the legacy system happens to hold.
Cleanse at the source, in the legacy system, wherever that is possible. Cleansing in spreadsheets between extract and load is repeated in every cycle and gets forgotten in one of them.
Cleansing starts now. It does not wait for the system to be installed.
Data is loaded through standard business logic, so invalid records are rejected at load. A rejection is a finding about the data, not a fault of the tool.
Every load is repeatable. Extract, transform and load steps are documented and rerun the same way in each cycle.
Every load is validated by the functional team that will use the data, against checks agreed beforehand.
Extracts contain real business data and are protected accordingly (section 9).
[Project-specific principle]

3. Scope by data object

List data objects at group level here. The plan breaks them down further.

Data group	Examples of objects	In scope	Source systems	Business owner	Notes
Example: Supplier master	Suppliers, addresses, payment terms, supplier for purchase part	Yes, suppliers with activity inside the period decided in section 4	[Legacy ERP], [spreadsheet held by purchasing]	Purchasing manager	Two sources overlap. Duplicates to be resolved before the first load.
Example: Inventory balances	Quantity on hand per part, location, lot	Yes, as of cutover	[Legacy ERP], confirmed by a count	Warehouse manager	Loaded at cutover only. Earlier cycles use a snapshot.
Basic data	[Units of measure, part groups, payment terms, delivery terms]	[Yes / No]	[Source, or "entered manually from the Book of Rules"]	[Role]	[Notes]
Master data	[Parts, customers, suppliers, price lists, structures]	[Yes / No]	[Source]	[Role]	[Notes]
Open transactions	[Open purchase orders, open customer orders, open balances]	[Yes / No]	[Source]	[Role]	[Notes]
Historical transactions	[Closed orders, transaction history]	[See section 4]	[Source]	[Role]	[Notes]
Documents and attachments	[Drawings, certificates]	[Yes / No]	[Source]	[Role]	[Notes]

Explicitly out of scope: [list, with the reason and where that data will remain available].

4. History depth decision

How much history is migrated is a business decision with a real cost. Record it once, with reasons, and have the steering group confirm it.

Question	Decision	Reasoning	Decided by, date
Are closed transactions migrated at all?	[Yes / No / Only for listed objects]	[Reasoning]	[Name, date]
Which master data records count as active?	Example: Suppliers and parts with activity since `[agree in project]`, plus records named by the owner	Keeps the new system free of dead records. Owners can nominate exceptions.	[Name, date]
How will users reach older data after go-live?	[Legacy system kept read-only until `[agree in project]` / Archive database / Exported reports]	[Reasoning]	[Name, date]
Which legal retention duties apply, and how are they met?	[Text, confirmed by finance or legal]	[Reasoning]	[Name, date]
Are open transactions migrated or run down in the legacy system?	[Per object]	[Reasoning]	[Name, date]
Are statistics or planning history needed for forecasting?	[Yes / No, which]	[Reasoning]	[Name, date]

5. Ownership

Responsibility	Customer	Supplier
Decide scope and history depth	Accountable	Advises
Identify sources and extract data	Accountable and does the work	Advises on target format
Cleanse data	Accountable and does the work	Reports findings from loads
Map legacy fields to target fields	Functional teams decide the meaning	Provides target structure and migration job design
Build and run migration jobs	[Agree in project: customer technical analysts after training, or supplier]	[Agree in project]
Validate loaded data	Accountable, done by functional teams	Supports with checks and queries
Sign off each data object	Business owner	Not applicable
Protect extracts	Accountable	Follows the agreed handling rules

Named business owners per data group are listed in section 3. Owners need released time for this work. Cleansing fitted in around the day job is the most common reason migration runs late.

6. Cleansing approach

Item	Description
Start	Now. The readiness checklist in template IDK-15 can be worked before the system is installed.
Where cleansing is done	[In the legacy system by default. Exceptions listed per object in the plan.]
Typical tasks	Remove duplicates, decide active records, complete mandatory classifications, rationalise units of measure, normalise reference values such as countries, fix structured fields such as postcodes, move content out of free-text notes
Renumbering	[Decision whether parts, customers or suppliers are renumbered, with the cross-reference kept where]
How findings from loads are fed back	[Rejected records listed per cycle, assigned to the business owner, corrected at source before the next cycle]
Progress reporting	[Measure per object, reported in the weekly project meeting]

7. Tooling and methods

Method	When it is used	Notes
Migration jobs in IFS Cloud (Data Migration Manager where licensed and agreed)	Medium and large data sets, anything loaded in more than one cycle	Loads through standard business logic. Jobs are reusable across cycles and at cutover.
Copy and paste or file import on standard pages	Small sets of basic data	Quick, but must be documented so it can be repeated
Manual entry	Very small sets, or data that needs a human decision per record	Doubles as training for key users. Record who enters what.
Configuration packages between environments	Basic data and configuration already verified in one environment	Not a migration from legacy, but part of the load sequence

Item	Decision
Extract tooling on the legacy side	[Tool, owner]
Transformation tooling	[Tool, owner. State whether transformation rules are stored as scripts or done by hand.]
Target environments per cycle	[Environment names]
Technical training needed for the customer team	[Course, attendees, timing]
Where mapping documents and job definitions are stored	[Link]

8. Load cycles, validation and reconciliation

8.1 Load cycles

Item	Value
Number of load cycles before the rehearsal	`[agree in project]`
Purpose of each cycle	Example: First cycle proves the jobs and the load order with a sample. Later cycles use full extracts. The last cycle before SAT runs with real security and feeds the SAT environment.
Entry criteria for a cycle	[Mapping approved for the objects in the cycle, extract delivered, environment ready]
Exit criteria for a cycle	[Rejections listed and assigned, validation checks run, results recorded]
Volume test	[Which cycle loads full volumes to prove run times]
Full rehearsal	In Implement Solution, with complete volumes, timings logged per step. More than one rehearsal is recommended.

8.2 Validation and reconciliation approach

Level	What is checked	Who	Evidence
Technical	Records extracted, records loaded, records rejected, with reasons	Migration team	Load log per job
Reconciliation	Example: Count of open purchase order lines and total open quantity per site in legacy equals the same in IFS Cloud	Business owner with migration team	Reconciliation sheet, signed
Financial	[Inventory value, open balances agree with the legacy ledger at the cutover date]	Finance	Reconciliation sheet, signed
Functional	Processes run with migrated data: a migrated part can be ordered, received and issued	Functional team	Test script result
Sample	Records picked by the owner compared field by field	Business owner	Sample log

Tolerances for reconciliation differences: [agree in project], decided by [role].

9. Security and privacy of extracts

Extract files hold prices, supplier and customer details and sometimes personal data. They travel outside the access control of both systems.

Topic	Rule
Storage location for extracts and load files	[Named location with access restricted to the migration team]
Transfer between customer and supplier	[Agreed secure channel. Not e-mail attachments.]
Personal data	[Which objects contain it, legal basis, approval by the privacy owner]
Use of production data in test environments	[Allowed / Masked / Restricted to named environments]
Who may access which environment holding migrated data	[Roles]
Retention and deletion of extract files	[Deleted `[agree in project]` after go-live sign-off, by whom, with confirmation]
Copies on personal devices	Not allowed

10. Cutover implications

Topic	Decision or approach
Timing	[Go-live date aligned with a financial period boundary, away from business peaks and holidays]
Legacy freeze	[When transactions stop in legacy, per area]
Static data loaded early	[Which objects are loaded before the cutover window, and how changes are kept in step until go-live]
Dynamic data loaded in the window	[Balances, open orders]
Duration of the migration steps	Taken from the rehearsal logs, not estimated
Point of no return	[Defined in the contingency plan, with the decision maker]
Backup	Production is backed up before release to users
Catch-up of transactions during the window	[How business done on paper during the freeze is entered]
Sign-off before release to users	[Business owners sign reconciliation, steering group or delegated authority releases]

11. Roles

Role	Name	Responsibility
Data migration lead (customer)	[Name]	Owns the plan, coordinates owners, reports progress
Business data owners	[Names per data group]	Scope, cleansing, validation, sign-off
Technical analysts (customer)	[Names]	Extracts, transformation, running migration jobs after training
Data migration consultant (supplier)	[Name]	Method, job design, support during loads
Application consultants (supplier)	[Names]	Target data structure, support for mapping decisions
Project managers	[Names]	Plan, resources, escalation
Privacy or security owner	[Name]	Approves handling rules in section 9

12. Risks

Risk	Mitigation	Owner
Sources and data quality understood too late	Inventory of sources and cleansing start in the first phase	[Name]
Owners not released for cleansing and validation	Time commitment agreed by the steering group, tracked in the project plan	[Name]
Too few full iterations	Number of cycles agreed and planned, rehearsal with full volumes	[Name]
Technical team not trained on the tooling	Technical training scheduled before the first cycle	[Name]
[Risk]	[Mitigation]	[Name]

13. Approval

By approving, the steering group confirms the scope outline, the history depth decision, the ownership model and the handling rules for extracts.

Role	Name	Decision	Date
Customer project manager	[Name]	[Approved / Approved with comments / Rejected]	[YYYY-MM-DD]
Supplier project manager	[Name]
Customer sponsor	[Name]
Steering group chair	[Name]

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