Sequence and validation windows

Migration objects cannot load in any order. A customer open item points to a customer. A purchase order points to a supplier, a product and a purchasing info record. An inventory balance points to a product that must already exist in that plant and storage location. If the referenced record is missing, the dependent load fails, or worse, loads against a default that no one intended.

The dependency chain

The cockpit tells the team which objects an object depends on, and the migration plan turns that into a load sequence. Configuration and organizational units come first, because every record refers to them. Then master data, from the most independent to the most dependent. Then open items and balances, which refer to master data. Finance balances usually come late, because they have to tie out against everything loaded before them.

For the business, the sequence matters because it sets when you can validate and what breaks if you are late. If customer master data has a wrong reconciliation account and nobody notices before AR open items load, every open item posts to the wrong G/L account. Fixing the customers afterwards does not move the open items.

Migration key date and balances

Open items and balances are loaded as of a migration key date, usually the last day of the period before go-live. The system needs that date set per company code before financial objects can load. Balances are posted against technical migration offset accounts so that each load balances in itself; once everything is in, the offset accounts should net to zero. That rule gives finance a powerful check, covered in lesson 3.

Mock loads and windows

There is a second reason to get early layers right. The cockpit is designed to create records, not to update records it already loaded. Correcting a wrong field on 1,800 loaded customers therefore means a separate mass-change step or, in a test client, a fresh load into a reset system. Either costs time that a go-live weekend does not have. Ask the migration team how corrections would be applied for each object before you need one.

Projects rehearse migration several times. Each mock load runs the full sequence into a test client, often with a full copy of production data, and each one should be validated as if it were real. Mocks are where business validation is practiced, timed and improved; the final load during cutover leaves little room for discovery.

Planning business validation windows

Luis, Contoso's cutover manager, owns the cutover plan. Business validation appears in it as tasks with owners, start times and durations, placed between loads. Priya, the test lead, helps the key users turn their checks into a repeatable validation plan. A practical plan lists, for each object:

• Owner: the named business validator, for example Maria for customers and open sales orders.
• Checks: the counts, totals and samples to run, with the report or app used.
• Source figures: the matching legacy figures, extracted at the same cut-off.
• Tolerance: what difference, if any, is acceptable (for example zero for balances).
• Window: when validation starts, how long it takes, and what load waits for it.
• Decision: who can accept the object or stop the sequence.

Time every check during mock 2. If Maria's customer validation takes four hours in the mock, it will not take one hour on go-live Saturday. Validators who measure their checks can tell Luis exactly how long a window they need; validators who guess are the ones who end up signing without checking because the clock ran out.