Lesson 3 of 5
Migration phases
11 min
Listen to this lesson
You do not need to run the finance migration activities yourself to plan and test around them. You do need to know their shape, because they sit on the critical path of the conversion weekend and each phase produces evidence. This lesson describes the phases conceptually. The exact activity list depends on the source release and is documented by SAP in the finance conversion note referenced from the conversion guide (SAP Note 2332030); always follow that for your release.
Where finance migration sits in the conversion
- Users locked, period closedBefore picture captured in ECC
- SUM technical conversionDatabase migration if needed, new software, automated data conversion
- Finance Customizing migrationLedger, asset accounting and other settings imported or completed, often from transports collected in the mocks
- Finance data migrationLine items, balances and asset values moved into the new structures; monitored in the migration monitor
- Reconcile and completeDifferences analyzed and resolved; migration set to complete
- Finance validationKey users compare reports and post first test documents
In a standard conversion, SUM finishes first, then the finance team runs the migration in the converted system. The activities are started and monitored from a migration monitor (transaction FINS_MIG_STATUS), which runs them in the right sequence, shows each run, and lets the team analyze errors and repeat or reset steps. A few activities, such as the SAP Credit Management migration, run separately as Customizing steps after SUM.
The conceptual phases
| Phase | What happens | What to look for |
|---|---|---|
| Customizing migration | Settings for ledgers, accounting principles, asset accounting and cost elements are migrated or completed | Errors here stop everything after; resolve them in the mocks and transport the result |
| Analysis and reconciliation before migration | The system checks the old data stores against each other | Differences found here are ECC problems that preparation should have caught |
| Enrichment | Old documents are enriched with fields the universal journal needs | Long runtimes on large document volumes; errors on unusual documents |
| Line item migration | Line items are written into the universal journal | Counts and runtime per company code |
| Balance migration | Opening balances and differences are migrated so totals match | Any balance that needed a difference posting is a reconciliation topic |
| Asset and material ledger steps | Asset values and depreciation, and material ledger data, are built in the new structures | Asset history sheet and stock value comparisons |
| Check and complete | Migration results are checked; the migration is set to complete so normal posting can start | Every open difference explained and accepted before completion |
Finance migration phases described conceptually. Activity names and order vary by release; follow SAP's note for yours.
Two points matter for planning. First, finance migration is repeatable in the mocks but not in production: in a mock you can reset a step and try again; on the real weekend every reset costs hours. Second, normal finance posting stays blocked until the migration is completed, so the completion step is effectively a finance go decision. Treat it as a checkpoint with Dan, not as a technical click.
Reading the migration monitor
Each activity in FINS_MIG_STATUS has a short step ID, for example ENR for enriching transactional data, R21 for a reconciliation of transactional data, and M10 or M20 for material ledger steps. The monitor runs them in dependency order. When an activity ends with unaccepted errors, the sequence stops and the activity shows red. There are only two ways on: fix the cause, then reset and repeat the activity, or accept the errors with a recorded reason. Accepting is a finance decision, so Dan or his delegate approves it, and every acceptance goes into the migration log and the sign-off file.
For a tester, the monitor is evidence, not just a technical screen. After each mock, export the activity list with statuses, run times and accepted errors, and attach it to the finance migration log. Compare it with the previous mock: the same activities should finish faster, and no new kind of error should appear.
Moving work out of downtime
On a large system, finance migration can take many hours. SAP's downtime-optimized conversion approach moves most of the finance and material ledger conversion into the SUM uptime, with changes made during uptime recorded and replayed, so only the delta is converted in downtime. It needs an SAP expert who has completed SAP's specialist training for the approach and more project effort. For a test lead the important point is that the evidence does not change: you still need a before picture and a full reconciliation.
| Standard conversion | Downtime-optimized conversion | |
|---|---|---|
| Finance migration timing | After SUM, inside the downtime window | Mostly during SUM uptime, with a delta in downtime |
| Effect on downtime | Runtime grows with document volume | Shorter technical downtime |
| Effort and skills | Standard SUM and finance migration skills | Specialist-trained SAP expert and a dedicated plan |
| Evidence needed | Before picture, reconciliation, sign-off | The same, plus checks that delta replay was complete |
Record durations in every mock
Luis needs realistic timings for the runbook. In each mock, record the start and end of every finance activity and every reconciliation, the number of errors and how long they took to resolve. In Contoso's Mock 1 the line item and balance migration was fast, but analyzing and resetting a failed enrichment step took four hours, which is why the team now fixes those documents in ECC before the weekend.
What would you do?
In Mock 2, the reconciliation activity R21 reports differences on three 2014 documents posted by an old interface. Fixing them in ECC would take two days. Sam asks whether he can simply accept the errors so the monitor continues. What should happen?
- Finance migration runs after SUM in a standard conversion and is monitored in FINS_MIG_STATUS.
- Phases: Customizing, pre-checks, enrichment, line items, balances, assets and material ledger, complete.
- Posting stays blocked until the migration is completed; treat completion as a finance checkpoint.
- Downtime-optimized conversion moves most finance migration into uptime but needs expert skills.
- Time every activity in every mock to feed the runbook.
Check your understanding · not graded
Lesson check
1. In a standard conversion, when does the finance data migration run?
2. Which transaction monitors and sequences the finance migration activities?
3. Why should setting the finance migration to complete be a checkpoint with the process owner?
4. What does downtime-optimized conversion change for finance?
5. A finance migration activity ends with errors in the monitor. What are the legitimate ways forward?