---
title: "Data Migration Strategy Template (IDK-14)"
date: 2026-09-21
description: "Ready-to-use template IDK-14: Data Migration Strategy for IFS Cloud implementation projects, 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 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](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/15-data-migration-plan-and-readiness-checklist)), 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.

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

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose and position in the project](#1-purpose-and-position-in-the-project)
- [2. Principles](#2-principles)
- [3. Scope by data object](#3-scope-by-data-object)
- [4. History depth decision](#4-history-depth-decision)
- [5. Ownership](#5-ownership)
- [6. Cleansing approach](#6-cleansing-approach)
- [7. Tooling and methods](#7-tooling-and-methods)
- [8. Load cycles, validation and reconciliation](#8-load-cycles-validation-and-reconciliation)
- [9. Security and privacy of extracts](#9-security-and-privacy-of-extracts)
- [10. Cutover implications](#10-cutover-implications)
- [11. Roles](#11-roles)
- [12. Risks](#12-risks)
- [13. Approval](#13-approval)

 ## 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](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/15-data-migration-plan-and-readiness-checklist)) |
| 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.

 
1. The business owns the data. Each data object has a named business owner who decides what is migrated and signs off the result.
2. Migrate what the new processes need, not what the legacy system happens to hold.
3. 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.
4. Cleansing starts now. It does not wait for the system to be installed.
5. 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.
6. Every load is repeatable. Extract, transform and load steps are documented and rerun the same way in each cycle.
7. Every load is validated by the functional team that will use the data, against checks agreed beforehand.
8. Extracts contain real business data and are protected accordingly (section 9).
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](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/15-data-migration-plan-and-readiness-checklist) 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 | Signature |
| --- | --- | --- | --- | --- |
| 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.

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