Home›Use cases›System change
◉ 3 examples from practice

System changes and migration
Moving without losing the history

A system change rarely fails on the new software. It fails because the history does not come along, because both systems have to run side by side for months, and because nobody can say for certain whether everything really arrived.

4 weeks instead of six months to the switchover estimated from comparable projects
6 monthstypical project length
4 weekswith parallel operation
0records lost
The starting point

What a system change
costs in time today.

1

The history stays in the old system because moving it would take too much work

2

Both systems run side by side and have to be kept in sync by hand

3

After the migration records are missing, and nobody notices straight away

4

With several countries every system holds different data

Programmes involved

These are the systems
tied to this area.

All already connected. If yours is missing, we build the integration at no extra cost, on average within three days.

Personio SAP SuccessFactors Workday Sage DATEV rexx systems

Is your programme included?

Three examples

Simple, medium
and genuinely complex.

All of them examples from live operation. What gets built is whatever comes up in your work.

SimpleA few steps, ready straight away

Move employee records into the new system

TriggerA decision for a new HR system

  1. Read the data from the old system
  2. Map the fields
  3. Write it to the new system

ResultThe base records are in the new system, with no retyping.

MediumWith conditions and approvals

Take the history and documents with you

TriggerA migration in preparation

  1. Export the contract history
  2. Assign the documents to each person
  3. Create the filing structure in the target system
  4. Check for completeness
  5. Log the deviations

ResultThe past moves too, not only the current state.

ComplexBranches, deadlines, several systems

Parallel operation across several countries

TriggerA staged switchover, three countries, different legal positions

  1. Prioritise countries and legal entities
  2. Build the field mapping per country
  3. Allow for legal particularities
  4. Keep both systems in step
  5. Reconcile changes during parallel operation
  6. Spot conflicts and report them
  7. Approve the switch-off country by country
  8. Generate the migration log for internal audit

ResultA system change in stages, without the data drifting apart in between.

The exceptions

And what about
the special cases?

That is the question most automation projects fail on. With us the exceptions get built in, not left out.

Aborting the migration and going back to the old system
Migrating while payroll is running
Different jurisdictions with different mandatory fields

Each of these cases can be mapped in the builder as its own branch, with a condition, an approval and a different route. Without a line of code.

Common questions

What we are asked about system changes
most often.

Does the history really come along?
Yes, that is the heart of it. The history of employee records, contract changes and documents all move across, not just the current state.
How long do both systems run side by side?
As long as you need. During parallel operation the reconciliation keeps both in sync, so nobody has to maintain anything twice.
How do we know everything arrived?
From the reconciliation report. It sets both sets of data side by side and lists every difference, rather than just reporting “done”.
What happens if we abort the switch?
The old records stay complete. Because we reconcile rather than overwrite, going back is possible at any time.
The next step

Tell us
what comes up in your work.

30 minutes on your actual programmes. We rebuild your system change workflow live, not on a made-up company.