Deutsch (Deutschland) 
Polski (PL) 
Independent IFS practice · Data migration out of IFS
Your IFS data, described field by field, ready for the SAP consultant or any other target ERP
The consultant who loads your new ERP can only map what they understand, and an IFS database holds years of customers, suppliers and parts, with duplicates and with fields whose meaning exists only in your IFS configuration. When the extract arrives without that explanation, every trial import returns a list of questions and the cutover date moves. I extract the data from IFS read-only, describe every field, flag duplicates and suspicious records, support your users while they cleanse, and adjust the export after each trial import. The target-ERP consultant maps and loads.
- IFS is only read: nothing is installed or changed in IFS
- One fixed file format and a description of every field
- Repeatable extraction scripts, so every export gives the same result
- SAP is the worked example here; the process is the same for any target ERP
Key takeaways
- The export file is the contract between IFS and the target ERP: fixed format, every field described, changes only through a logged question and decision list.
- The work runs as five steps with five checkpoints. Step 1 happens once, steps 2 to 5 repeat in three planned cycles: trial import, full volume, final run.
- After every cycle four figures are reconciled: records in IFS per criteria, duplicates merged, records excluded with a reason, records in the target after import. A cycle with unexplained differences stays open.
- Scope is empty by default and every object is added deliberately, with a selection criterion such as customers with a purchase in the last 5 years.
- A change request from the target side changes the extraction script, never the file by hand, so the next export on current data repeats the fix.
1.Where does my scope end and the target consultant's begin?
The IFS consultant's scope ends at the described export file. Everything that happens to the data after it leaves IFS, from mapping to the target ERP's templates through to the final import, belongs to the target-ERP migration consultant, and the substantive cleansing belongs to your users. Three parties work together: your users, the IFS consultant and the target-ERP consultant.
| In my scope (IFS consultant) | Outside my scope (target-ERP consultant and client users) |
|---|---|
| Repeatable extraction scripts for IFS | Mapping my files onto the target ERP's templates |
| Excel files with a description of where every field comes from | Transforming the data into the target ERP's format |
| Flagging duplicates and suspicious data | Trial and final import into the target ERP |
| Consultations with your users and with the target-ERP consultant | Cleansing and acceptance of the data (client users) |
| Changes to the export after each trial import | Configuration and validation in the target ERP |
Decisions to merge or exclude a record are taken by your users. I point at the suspicious data and explain what each field means in IFS.
2.What does it mean that the file is the contract?
The export file is the contract between IFS and the target ERP because its format is fixed, every field in it is described, and any change goes through a written, versioned log. Four rules make that work.
- Fixed file format - I do not adapt the file to the target ERP. The target-ERP consultant maps it, which is why the format of my file does not change between cycles.
- Every field has a description - where the field comes from in IFS and what it means.
- Changes go through a log - questions and needs from the target side are written down and versioned in the question and decision log.
- Scripts, not manual fixes - a change of the export mechanism goes into the extraction script and never into a hand-edited export file, so every export can be repeated with the same result.
Data flows in one direction: IFS, then Excel export files with field descriptions and flags, then cleansing by your users, then mapping and import by the target-ERP consultant. IFS is only read. Your users cleanse the data in the exported files, and a change of the export mechanism is made in the extraction script. This works with IFS Cloud and with on-premise IFS Applications. The channel used for read-only extraction depends on the version and the hosting model, and it is agreed in step 1.
3.What are the five steps and their checkpoints?
The migration out of IFS has five steps, and each ends in a checkpoint that must be met before the next step starts. Step 1 is done once at the start. Steps 2 to 5 repeat in migration cycles until the import into the target ERP passes without errors.
| Step | What happens | Checkpoint | Deliverables |
|---|---|---|---|
| 1. Scope and schedule | I agree with your contact persons which data I export and by when. Contacts for sales, finance, project and the target ERP, objects in scope, selection criteria, cycle dates agreed with the target-ERP consultant. | Scope approved | Contact list, object register, selection criteria, cycle schedule, access to IFS data, consultation plan, question and decision log |
| 2. Export from IFS | I extract with scripts I can run repeatedly and hand over Excel files: one file per data object, every field described, suspected duplicates and gaps flagged, the same script in every cycle. | Files handed over | Extraction scripts, Excel files, suspicious records, field dictionary |
| 3. Verification and cleansing | Your users review the files with me explaining each field: they remove and merge duplicates, fill gaps, correct errors and decide whether a record is migrated or skipped. | Data accepted | Cleansed files, merge list, exclusion list, questions to the source, area acceptance |
| 4. Mapping and import | I explain the fields in sessions with the target-ERP consultant, who maps them and runs the trial import. My file format does not change. Questions and new needs come back to me. | Trial import done | Files handed over, consultation notes, target-ERP question log, trial import result |
| 5. Corrections and acceptance | I change the export mechanism according to what the import showed, until the data lands in the target ERP without errors. Export again on current data, cleanse only new records, final export in the cutover window. | Data in the target ERP | Final files, new script version, record reconciliation, acceptance protocol |
4.How do the three cycles and the four reconciliation figures work?
A migration out of IFS runs in three export-to-import cycles before the target ERP goes live: a trial import, a full-volume run and a final run. Each cycle repeats steps 2 to 5 with the same script on current data. The schedule is indicative, and the number of cycles and the import dates are agreed with the target-ERP consultant in step 1.
After every cycle we reconcile four figures between IFS, the file after cleansing and the target ERP:
- Records in IFS - counted according to the agreed selection criteria.
- Duplicates merged - the decisions of your users.
- Records excluded - each with a stated reason.
- Records in the target ERP - counted after the import.
The numbers match or we know why. A cycle with an unexplained difference is not closed.
The feedback loop is a normal part of the process. After a trial import the target-ERP consultant reports questions, gaps and new needs. I modify the script and do not edit the file by hand, run the export again on current data, and your users cleanse only the difference. Each run is repeatable: the same script, current data, a predictable result.
5.Which data goes into the export and which stays out?
The default scope of the export is nothing, and each data object is added deliberately with a selection criterion. Master data is in scope for certain, and the remaining objects are settled at the scope workshop. The table shows the preliminary scope with example criteria.
| Data object (area) | Example selection criterion |
|---|---|
| Customers (sales) | Purchase in the last 5 years |
| Suppliers (finance) | Invoice or order in the last N years |
| Parts (sales) | Movement or stock in a chosen period |
| Projects (project) | Open projects and projects in progress |
| Open balances (finance) | To be decided: migrate or enter manually |
Duplicates are flagged already at export, so your users meet them at the start of cleansing and not after the first import. There is one script per data object, run as many times as the cycles require. A dictionary with fewer than 20 entries is faster to enter manually in the target ERP than to migrate.
6.How are consultations planned?
Consultations are a separate item in the plan and in the quote, because explaining where data comes from takes time that a pure export estimate does not contain. There are two kinds: with the target-ERP consultant about the meaning of fields and questions after import, and with your users about the origin of data and support during cleansing. They take place after the export and after every trial import, against the question log, at a fixed weekly slot. The hours are sized after the scope workshop, when the objects and criteria are known.
7.What can delay the migration and how is each risk handled?
Five risks delay a migration out of IFS, and each has a countermeasure built into the plan. The risks are reviewed at every status meeting.
| Risk | Countermeasure |
|---|---|
| Unclear data scope | Scope and criteria approved in step 1 |
| Client people not available | Named people and dates in the schedule |
| Cleansing takes longer than planned | Duplicates flagged already at export |
| New target-ERP needs after import | Repeatable scripts and the next cycle already in the plan |
| Consultations underestimated | Consultation time as a separate plan line |
8.What do I need before the first export?
I need five contacts before the export starts, and the names and details of the contact persons and of the target-ERP consultant are the condition for starting step 1.
- Sales - contact person for customers and parts.
- Finance - contact person for suppliers and balances.
- Project - contact person for projects.
- Target ERP - the migration consultant (for SAP, the SAP migration consultant).
- IT - access to the IFS data.
With the area contacts I agree the export scope and the way of cleansing. With the target-ERP consultant I agree cycle dates and how files are handed over. Five agreements are made before the first script exists:
- Data objects in the migration scope.
- Selection criteria for each object.
- Contact persons from the areas and the target-ERP consultant.
- Who cleanses which data and by when.
- Dates of the cycles and of the imports into the target ERP.
The contact list, the object register and the question and decision log are the working documents of this process. How such documents are kept across an IFS project is described in the Implementation Documentation section.
9.Frequently asked questions
Does the IFS extraction work for a target ERP other than SAP?
Yes. The extraction from IFS is the same for any target ERP, because I deliver a fixed file format with a description of every field and the target-ERP consultant does the mapping to the target's own templates. SAP is the worked example on this page; the steps, files and checkpoints do not change with the target system.
Does the extraction change anything in our IFS system?
No. IFS is only read, and nothing is installed or changed in it. Corrections are made in the exported files during cleansing or in the extraction script when the export mechanism changes. The process works with IFS Cloud and with on-premise IFS Applications, and the read-only channel is agreed per version in step 1.
Do you map the data to SAP templates and import it?
No. Mapping to SAP templates, transformation to the SAP format, the trial and final import, and configuration and validation in SAP belong to the SAP migration consultant. The IFS consultant delivers the extraction scripts, the Excel files with field descriptions, the flagged duplicates and suspicious data, the consultations, and changes to the export after each trial import.
How many migration cycles does an IFS data migration need?
An IFS data migration plans three export-to-import cycles before the target ERP starts: a trial import, a full-volume run and a final run in the cutover window. The exact number of cycles and the import dates are agreed in step 1 with the target-ERP consultant, and the cycles repeat until the import passes without errors.
How do you prove that no records were lost between IFS and the new ERP?
After every cycle four figures are reconciled: records in IFS per the selection criteria, duplicates merged, records excluded with a reason, and records in the target ERP after import. The numbers match or the difference is explained, and a cycle with an unexplained difference is not closed.
Which IFS data should not be migrated?
The scope of an IFS data migration starts empty, and each object is added with a selection criterion, for example customers with a purchase in the last 5 years, suppliers with an invoice or order in the last N years, parts with movement or stock in a chosen period, open projects and projects in progress. Dictionaries with fewer than 20 entries are entered manually in the target ERP, and open balances are decided case by case between migration and manual entry.
What if I am migrating data into IFS Cloud and not out of it?
Inbound migration into IFS Cloud is a separate topic with its own tools and load sequence. If you are moving to IFS Cloud, see the data migration section of the marketplace.
10.About the author
Dariusz Myśliwiec: independent IFS consultant, 18 years on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, working remotely across Europe and globally. You talk to the consultant who writes the extraction scripts and explains the fields to your users.
Selected IFS clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB. SAP is a registered trademark of SAP SE; this practice is not affiliated with SAP SE.
Start with the scope and schedule workshop
The next step is a workshop on scope and schedule: contacts from sales, finance, project and the target-ERP consultant, the data objects and selection criteria, and a cycle schedule agreed with the target-ERP consultant. No pitch. Talk to the consultant who builds the extraction.
Book a 30-minute technical call See Implementation Documentation
