Home · Solutions · IT & services
Solution · IT & servicesEvery migrated record checked against the source before anyone signs the cutover
Data migration validated by testing, not spot checks
Automated test cases reconcile source and target field by field for every migrated record, rerun the business flows on the migrated data, and produce the evidence the go-live decision needs.
Executive summary
A spreadsheet sample of a few hundred records is what currently stands between your migration and go-live.
We build migration assurance as test assets rather than a spreadsheet exercise.
Coverage stops being a matter of opinion: every record in scope is compared on every mapped field.
SAP S/4HANA through SAP BAPI and OData; the Azure DevOps backlog; the Test Manager evidence record
Business problem
Migration assurance
A migration moves the company's operating memory into a new system: customer and vendor master records, bank details, material data, pricing conditions, open receivables and payables, ledger balances, open orders. Every object has an owner somewhere in the business who is asked to confirm that the data looks right. The tool they are given is an extract and a spreadsheet.
Sampling is not coverage. Three hundred customer records out of four hundred thousand says almost nothing about the rest, and samples are biased: people check the accounts they recognise. Dormant customers, rare configurations and the long tail of open items are where migration rules break. Five companies, several waves and three mock runs multiply the same manual comparison, so by the third run the business checks less, exactly when the data is closest to production. The technical report stays green, because counts matching is not values being right.
The consequences land on people who were never in the migration meetings. Collections chase customers for items closed years ago. A blocked delivery turns out to be a credit limit that migrated as zero. Sales finds a price condition table that lost its validity dates. Treasury finds a payment run pointing at a supplier's old factoring account. Each is found weeks after cutover was declared a success.
How it works today
In most conversion programmes the real test plan is a stack of Excel comparison sheets, whatever the migration tooling.
- SystemThe mock load runs over the weekend; the cockpit reports record counts and load errors per object
- PersonAnalysts pull extracts from both systems and build comparison sheets in Excel per object
- PersonEach business team opens a sample of a few hundred records and checks the fields it knows best
- WaitingFindings sit in a shared tracker until the next programme call, usually a week later
- Risk of errorObjects without a clear owner, such as pricing conditions and partner functions, are checked last or not at all
- PersonSign-off is a signature on a checklist; the sample size behind it is recorded nowhere
- Risk of errorThe first complete test of the data is the business, on the first working day after go-live
Why the current process costs more than it appears
Nobody planned this work; it accumulated.
- Repetition is the hidden line item. The same comparison is rebuilt for every mock run and every wave, and none of it survives, because it lives in a spreadsheet.
- Sign-off without a recorded sample size is not evidence. Asked later how the opening balances were verified, the honest answer is that some people looked at some records.
- Defects cost several times more after go-live. In a mock run a defect is a line in a tracker; in production it is a stopped delivery, a wrong dunning letter and a correction posting finance explains at the close.
- Fear of the data slows the programme. When nobody can quantify the risk, the reflex is another mock run or a longer freeze, both expensive.
Cost of inaction
The second row is the one that moves. Manual checking is bounded by the days available, so there is a ceiling on what it costs; the defects that slip past it are bounded by nothing. One wrong bank account on a vendor master, or open items that lost their due dates, can each consume more management attention than the whole checking budget. A third cost appears in no row at all: a programme that cannot quantify its data risk manages it by delay, and another mock run or a longer freeze is expensive precisely because the knowledge is missing.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A European industrial group, five operating companies in four countries, roughly 4,000 employees, converting from SAP ECC to SAP S/4HANA in two waves; Microsoft 365 E3, Azure DevOps for the programme backlog.
About 2.4 million records across roughly eighteen migration objects: customer and vendor master data with bank details, material master, pricing conditions, open AR and AP items, GL balances, open orders. Three mock migrations before cutover.
After each load the data team publishes extracts, six business checkers compare samples in Excel for about eight working days, findings go into a tracker, each owner signs a checklist.
The sample covers a fraction of one percent per object and skews towards familiar records; it cannot be repeated fast enough for three loads, so coverage falls when the data matters most.
Test Manager holds a reconciliation test case per object; robots read both systems through SAP interfaces, compare every record field by field, then run order-to-invoice and procure-to-pay flows on the migrated data. Deviations become defects in Azure DevOps and triage tasks in Microsoft Teams; the execution history is the sign-off evidence.
In the modelled case coverage moves from a sample in the low hundreds per object to every record in scope, each mock run is checked in hours rather than days, and defects previously found after go-live appear on the first load. These figures are a model, not a measurement.
Proposed solution
We build migration assurance as test assets rather than a spreadsheet exercise. Each migration object gets a requirement and a reconciliation test case in UiPath Test Manager, the component of UiPath Test Cloud that holds test cases, test sets, execution history and evidence. The test case does at full volume what analysts were doing by hand: read the source records, read what landed in SAP S/4HANA, apply the mapping rules, report every record where the two sides disagree. Robots read through SAP interfaces rather than screens, so the comparison covers millions of records inside a load window.
Reconciling fields is not enough. A customer with a correct address can still carry a credit segment that blocks every order, so the same test set includes business-flow test cases on migrated data: a sales order for a migrated customer, delivery, invoice, incoming payment, dunning on a migrated open item. These are the flows the business runs on Monday, executed on Friday's data.
The rest makes the result defensible. Deviations are classified by rule, grouped by object and severity, and pushed into the Azure DevOps migration backlog. The owner of an object gets a triage task in Microsoft Teams with the record identifiers attached and decides to fix, accept with a reason, or reject the load. Test Manager keeps coverage, pass and fail counts and evidence per run, which is what a go-live gate needs instead of a signature. This is a different discipline from nightly release regression on a running SAP system, though the migration assets seed exactly that suite after go-live.
UiPath Test Cloud with Test Manager (test cases, test sets, execution evidence, Azure DevOps sync); UiPath Orchestrator schedules, queues and audit; UiPath SAP automation (SAP BAPI and OData connectors, SAP GUI activities); UiPath Action Center actionable notifications in Microsoft Teams; UiPath Insights Test Manager dashboard
The reconciliation test case per object, mapping and tolerance rules translated into assertions, the deviation classification, the business-flow test cases, defect routing and severity model, the deviation extract and readiness reporting
Reads from SAP ECC and SAP S/4HANA through UiPath SAP activities; staging of the comparison sets in Azure SQL where volume exceeds a spreadsheet
How the automated process works
- AutomationEach mock load triggers the reconciliation test set in Test Manager for every object in scope
- SystemRobots read the source records and the S/4HANA target through SAP interfaces and stage both sides
- AutomationEvery record is compared field by field; deviations are classified as missing, changed, truncated, wrongly assigned or outside tolerance
- AutomationBusiness-flow test cases run on the migrated data: order to invoice, dunning on a migrated open item, goods receipt against a migrated purchase order
- SystemResults, record identifiers and evidence go to Test Manager; defects synchronise into the Azure DevOps backlog
- PersonData owners triage their deviations as Action Center tasks in Microsoft Teams and decide fix, accept or reject
- AutomationA readiness view shows coverage per object, open defects by severity and the trend across mock runs
Human-in-the-loop model
Automation handles
- Field-level comparison of every record in scope after each load
- Classification of deviations by type, object and severity, with record identifiers
- Execution of the business flows on migrated data and capture of their evidence
- Defect creation in Azure DevOps, readiness reporting, and the rerun after each fix
People decide
- What "correct" means per object: fields in scope, intended transformations, tolerable differences
- Whether a deviation is a defect, an accepted difference, or a mapping error
- The severity model and what may still be open at the cutover gate
- The go-live decision, taken on evidence rather than a sample
Before and after
Systems and integrations
Every entry can be checked in vendor documentation. The evidence class is stated next to each one.
Inputs
- SAP ECC records per object
- the field mapping specification
- migration cockpit load results
- the cutover plan
Automation layer
- UiPath Test Cloud with Test Manager
- UiPath Orchestrator
- UiPath Robots
- UiPath Action Center
- Azure SQL staging
Target systems
- SAP S/4HANA through SAP BAPI and OData
- the Azure DevOps backlog
- the Test Manager evidence record
Human touchpoints: Action Center tasks in Microsoft Teams; a Teams channel per wave; the Excel deviation extract
Technologies used
test cases, test sets, execution history and sign-off evidence per object
Arun the test sets against both systems on schedule, with retries and audit
Areads source and target records; drives the flows on migrated data
Astages the comparison sets; holds technical credentials
Adata owners triage and accept deviations where the programme talks
Amigration backlog: defects linked to their test results, synchronised from Test Manager
Athe per-object deviation extract an owner works through
Acoverage, pass rate and defect trend across mock runs
AIllustrative economic model
The arithmetic is open, so it can be argued with.
Conversion programmes are where these ranges come from; none of them is a client measurement. Migration assurance is not a per-transaction process, so we show a value pool rather than a calculator. Check effort counts only the days business checkers spend comparing extracts. The €45 rate is a fully loaded blend of key users and IT analysts in Central Europe; the €14,000 per production defect is a modelled average across correction work, disruption and the finance rework to make balances tie.
Business benefits
- Coverage stops being a matter of opinion: every record in scope is compared on every mapped field
- Defects surface on the first mock run instead of in front of a customer, when fixing one is a mapping change rather than a correction posting
- Each run is checked in hours, so the programme can afford to reload after a fix instead of accepting known bad data to protect the schedule
- Go-live becomes a decision with evidence behind it, and the test assets outlive the migration as the regression baseline
The management view
- Cutover readiness is a number per object rather than a status colour agreed in a call, so go-live is discussed as facts rather than confidence
- Programme risk becomes reportable to the board and the audit committee: what was tested, what failed, what was accepted and by whom
- Migration knowledge sits in test cases rather than with consultants who leave at project close
Board-level KPIs
Security and governance
An auditor should be able to reconstruct every decision.
- Robots read both systems with technical accounts holding display authorisation only; the reconciliation flow needs no write access
- The boundary is your own Azure subscription, your tenant and an EU-region tenant of UiPath Automation Cloud; comparison sets are staged inside it and deleted on a schedule, and customer, vendor and bank data never move outside it
- Credentials sit in Azure Key Vault referenced from Orchestrator, and every read is attributable to a named account in the audit log
- Test Manager keeps the execution history, so who accepted which deviation and when is answerable months later, which is what an auditor asks about opening balances
Why now
Conversion programmes run against a fixed horizon: SAP provides mainstream maintenance for SAP Business Suite 7 core applications until the end of 2027, with optional extended maintenance until the end of 2030 at a premium. Manual checking does not scale into that window.
The illustrative €220,000 pool sits inside one migration year and cannot be recovered; a defect missed before cutover is paid for at production prices.
Test Manager now holds requirement-to-test traceability, execution evidence and Azure DevOps sync, and covers SAP and interface testing in one place, so this needs no reconciliation programme built for a single project.
Relevant executive roles
Opening balances, open items and vendor bank details are signed off against evidence rather than a sample, which is the version that survives an audit
Cutover readiness becomes a measurable gate, and the migration assets keep working as the regression suite
The first day after go-live is a normal day, because the order and invoice flows already ran on migrated data
Common questions and objections
They share a platform and little else. Nightly regression protects a running system from the changes you deploy into it; migration assurance proves a one-time data move landed correctly, record by record, before anyone signs. The connection worth having is that migration assets seed that regression suite after go-live.
Counts prove rows arrived, not that values are right. They match perfectly while a date is truncated, a unit of measure is converted twice, or a credit limit lands as zero. Field-level comparison answers the question the business feels afterwards.
Reading through interfaces rather than screens changes the arithmetic, and objects run in parallel across robots. For the production load the comparison is scoped to the objects the gate depends on, the full set having been proven in the mock runs.
When this is not the right solution
- A migration of a few thousand records into one object, where an analyst can genuinely compare both sides in a spreadsheet
- The field mapping still changes weekly and no object has a named owner; the rules have nothing stable to test against
- Neither the source system nor a frozen extract can be read after cutover, so there is no trustworthy left-hand side
A question for the next management meeting
When we sign the cutover, what percentage of the migrated records will anyone have actually compared against the old system, and can we show it?
Implementation approach
Delivery runs in stages, so it can be stopped at any point.
We deliver
- A scoping pass over the object list: which objects, which fields, which transformations, who owns each
- Reconciliation test cases in Test Manager per object, with mapping rules expressed as assertions and tolerances
- Interface reads against both systems, and the staging that makes a million-record comparison finish inside a load window
- Business-flow test cases on migrated data across order to invoice, procure to pay and dunning
- Defect routing to Azure DevOps and Microsoft Teams, readiness reporting, and the evidence pack for the go-live gate
We need from you
- The field mapping specification, even if it is still incomplete
- A named data owner per object who can decide what counts as a defect
- Technical read access to both systems, a mock environment, and the cutover plan with its gates
Stages
Scoping
Objects, fields, owners and the definition of correct, agreed with the business
Design
Reconciliation rules, tolerances, deviation classes, severity model, gate criteria
Build
Test cases in Test Manager, interface reads, staging, Azure DevOps sync, Teams routing
Mock runs
Full reconciliation on each load, defect triage, rerun on the fixes, coverage reporting
Cutover
Reconciliation on the production load, then handover of the assets as a regression suite
Departmental. Effort is driven by the number of migration objects, how precisely the field mapping is documented, and whether both systems can be read through interfaces or only through screens.
Sign-off says the data is correct. The sample behind it is a fraction of one percent.
Send us your migration object list and the field mapping specification, even in draft. We return a proposed reconciliation scope per object and an error taxonomy for the first mock run.
Scope one migration object with usThe neighbouring process usually has the same problem
Stop closing the month by downloading balances into Excel and chasing sign-offs by email.
View solution Supply chainProduct and price master data published to every channelStop retyping every new product and price change into the ERP, the PIM, the web shop and each marketplace.
View solution Legal & complianceSegregation of duties checked weekly, not once a yearThe auditor finds your role conflicts once a year. By then the oldest of them is twelve months old.
View solution IT & servicesEvery release regression-tested, including the phoneRegression is a checklist two people click through on the last afternoon before a release.
View solution Case studySAP regression every nightInstead of three people clicking for two days — UiPath test agents walk the critical SAP paths every night.
View case study Case studyRobots that heal themselvesAn SAP screen changes and half your robot portfolio stalls? Healing Agent detects the interface change and repairs selectors on the fly, and our AMS team guards the whole.
View case studyIndustries we deliver this in most oftenManufacturing & industryRetail & e‑commerceFinance & insurance