IKSAP Product
TPOT — Controlled Data Migration from SAP HCM to SuccessFactors
Test, approve, roll back.
TPOT is IKSAP’s data migration platform for moving data from SAP ERP HCM or another HR system (HRIS) to SAP SuccessFactors Employee Central (EC) and Employee Central Payroll (ECP). Mapping rules are written on screen by the consultant, every load is first run in trial mode, writing to the live system requires separate approval, and because the target address of every written record is stored, an incorrect load can be rolled back. The tool runs on its own server; nothing is installed on the customer’s SAP system. It makes data migration, the riskiest step in moving from HCM to SuccessFactors, controlled, traceable and reusable.
What goes wrong in data migration?
In moving from SAP HCM to SuccessFactors, data migration puts the most pressure on the project timeline, and the problems are always the same:
Rules live in Excel.
Mapping logic stays in files; once the project ends, the reasoning behind it is lost.
Loads cannot be undone.
If there is no record of where a written record went in the target, clean-up is manual, and the test environment is often refreshed.
Missing data slips through silently.
When the source response is cut off or tables do not match, no error is raised; the gap surfaces in production.
The wrong order breaks links.
When dependent objects are loaded in the wrong order, broken references remain in the target; the cost is rebuilding.
Starting from scratch on the second project.
Mapping built in one project cannot be handed over to the next; the effort is spent again.
How does TPOT solve it?
No waiting for developers.
Rules are written on screen and tested without saving; there is no waiting for a developer cycle.
You see errors first.
Every load opens in trial mode; the result of each row is visible before anything is written to production, and rejected rows are reported with the reason.
Incorrect loads are rolled back.
The target address of every record is stored; rollback touches only those records, the environment is not refreshed and the project does not stop.
The SAP team is not a bottleneck.
The tool runs on its own server; on the SAP side only a read-only service is used, so the source system is not strained.
Effort is not lost on the second project.
Templates, code translations and load sequence move to another project in a single package.
How does it work? — Four steps
- 1
Read
Only the fields used by the template are read from SAP; unnecessary data is never extracted.
- 2
Transform
Mapping rules and code translations are defined on screen and tested instantly; every rejected row is listed with the reason.
- 3
Load
Run in trial mode and review the result; writing to production is done with separate approval. If a load is interrupted, it is not restarted but resumes where it left off.
- 4
Roll back
An incorrect load is deleted using the stored target addresses; no manual clean-up.
Test → approve → load; roll back if needed. Every run is logged.
How is it different from the traditional approach?
| Criterion | Manual / traditional | TPOT |
|---|---|---|
| Mapping rules | In ABAP or Excel, dependent on developers | Written in the interface, no coding |
| Error correction | Manual correction or environment refresh | Rollback from stored addresses |
| Production safety | Trial in test environment; manual clean-up after errors | Trial mode; separate approval to write to production |
| Installation | Package installation on the customer’s SAP system | No installation on SAP; runs on the IKSAP server |
| Reuse | Mapping rebuilt on most projects | Template package carries over from project to project |
Security and traceability
Nothing is written to production by mistake.
The load screen opens in trial mode; writing to the live system requires separate approval.
Who loaded what is recorded.
Load, write-to-production and rollback operations are written to a read-only log that cannot be changed afterwards; audits do not rely on the team’s memory.
Testing does not affect production.
Development, test and production systems are defined separately within the same project; data for each customer → project → system scope is kept separate.
Data is not retained.
TPOT is an intermediate layer: it moves data but does not retain it; run logs and target addresses are stored only for audit and rollback.
Which migrations is it used for?
SAP ERP HCM → SuccessFactors Employee Central
Organizational (Foundation) objects, employee master data, compensation and contact information.
SAP ERP HCM → Employee Central Payroll (ECP)
Projects where EC and ECP are implemented together for the move to payroll.
Hybrid setups
Initial load between payroll remaining in HCM and modules moved to SuccessFactors.
Other HRIS → SuccessFactors
Data from a non-SAP HR system is also moved to Employee Central with the same template and test–approve–load flow.
Frequently Asked Questions
What is TPOT?
IKSAP’s template-based data migration platform that moves SAP HCM data to SAP SuccessFactors Employee Central and ECP: rules are written on screen, loads are tested first, writing to production requires separate approval, and incorrect loads are rolled back.
Does TPOT require installation in my SAP system?
No. TPOT runs on IKSAP’s server; on the SAP side only a read-only service is used. There is no waiting for the SAP team’s schedule, and the source system is not strained.
How is wrongly loaded data cleaned up?
The target address of every record is stored; rollback deletes only those records. No manual Excel clean-up or environment refresh is needed, and the project does not stop.
What is test mode?
The load is run without writing to the live system; the result of each row and the reason for rejected rows are visible. If the result is acceptable, writing to production is done with a separate approval.
Let's run the migration as a pilot together.
A limited scope: a few Foundation objects or the employee data of one company code. Let’s review the result together in trial mode, then decide on production.