Lesson 5 of 5
Business acceptance of migrated data
8 min
Business acceptance is the formal statement that migrated data is fit to run the business on. It is signed per object, or per group of objects, by the business owner of that data, and the set of acceptances becomes one of the inputs to the go/no-go decision. It is not a statement that the data is perfect. It is a statement that the owner knows exactly what the data contains, including its known exceptions, and is willing to operate with it.
Who signs what
| Data | Signs at Contoso | Why this person |
|---|---|---|
| Customers, open sales orders, prices | Maria (order-to-cash key user), for the process owner | Uses the data daily and knows the legacy records |
| G/L balances, AR and AP open items, assets | Dan (finance process owner) | Accountable for the opening balance sheet |
| Products, BOMs, inventory | Plant key users and plant controllers | Know physical stock and costing |
| Overall data acceptance | Process owners collectively, recorded by Grace (PMO) | Feeds the go/no-go decision |
Acceptance belongs to the people who own the data, not to the migration team.
What an acceptance record contains
- The object or group, the load cycle and the system and client (for example production load, client 100 in QAS for the dress rehearsal).
- The checks performed: counts, totals, profiles and samples, each with source and target figures and the result.
- Open differences accepted as exceptions, each with impact, owner and correction date.
- Expected differences and the rules that explain them.
- The decision: accepted, accepted with exceptions, or rejected, with name, role and date.
Usable, not just correct
Matching counts and totals prove the data arrived. They do not prove the business can work with it. In the dress rehearsal, add a short set of process checks on migrated data: create a delivery for a migrated open sales order for Great Lakes Fleet Services, post a goods receipt against a migrated open purchase order from Lakeside Components, run a payment proposal that includes migrated payables, run a dunning proposal on migrated receivables, and issue a migrated CMC-RTR-200 from stock. Each of these exercises fields that counts never touch, such as partner functions, schedule lines, payment methods and dunning keys.
These checks do not replace integration testing. They prove that the specific records loaded this weekend work in the processes that will run on Monday morning.
Go-live weekend: acceptance under time pressure
On go-live weekend the same checks run against production, inside the windows Luis rehearsed. Business validators should have their source figures prepared before the load starts, their reports saved as variants, and a clear rule for what stops the sequence. Typical stop rules: G/L balances do not tie out; offset accounts do not net to zero; bank details differ on any supplier; a count difference on a critical object that cannot be explained within the window.
- Friday eveningLegacy closed and extractedSource counts and totals frozen at the migration key date and handed to validators
- SaturdayMaster data loadsValidators accept business partners and products in their windows; dependent loads wait
- Sunday morningOpen items and balancesFinance ties out AR, AP, inventory and G/L; offset accounts at zero
- Sunday afternoonData acceptance completeSigned acceptances, with exceptions, go to the go/no-go meeting
Linking acceptance to go/no-go
The go/no-go meeting weighs data acceptance alongside test results, cutover progress, training and support readiness. A rejected object on a critical path, such as G/L balances, is normally a "no-go" or a "go with conditions" decision that the steering group must take explicitly. Accepted exceptions become hypercare items with owners and dates, so they are tracked after go-live instead of forgotten.
- Are all critical objects accepted?Yes → check exceptions · No → recommend no-go, or a conditional go decided by the steering group
- Are all exceptions listed with impact, owner and date?Yes → check financial tie-out · No → complete the acceptance records before the meeting
- Do sub-ledgers tie to the G/L and offset accounts net to zero?Yes → data recommendation is go · No → finance cannot accept the opening balance sheet
After go-live
Keep the acceptance records and the validation evidence with the project documentation. Auditors often ask how opening balances were established, and the answer should be a signed acceptance with the reconciliation behind it. During hypercare, track each accepted exception to its correction, and watch for user-reported data problems that suggest a validation gap. Those lessons improve the validation plan for the next migration, such as a later rollout to another company code.
What would you do?
It is Sunday afternoon on Contoso's go-live weekend. All objects are accepted except customers: 14 of 1,842 customers have the wrong sales district, which affects only a sales report. Maria cannot fix them before the go/no-go meeting. What is the best action?
- Business acceptance states the data is fit to operate, with known exceptions listed.
- The data owner signs, not the migration team.
- An acceptance record holds checks, results, expected differences, exceptions and the decision.
- Prepare source figures and stop rules before go-live weekend.
- Data acceptance is an input to go/no-go; exceptions become tracked hypercare items.
Check your understanding · not graded
Lesson check
1. Who should sign acceptance of migrated G/L balances at Contoso?
2. What must accompany an acceptance with open differences?
3. Which is a reasonable stop rule on go-live weekend?
4. What happens to accepted exceptions after go-live?