Do the old and the new system deliver the same correct result?
A migration is often the urgent trigger: S/4HANA, a new core-banking system, the move to the cloud. SQACE verifies that the target system delivers the same correct business results as the legacy system, rule-based and at scale.
Trigger An urgent migration, initially at project level. Often the first point of contact with SQACE.
A migration runs through and looks finished.
The run does not fail. The target tables are filled, the totals look plausible, the project reports completion. Whether every position was carried over correctly in business terms, no one knows for certain at that point.
Changed data types, rounded amounts, a shifted cut-off logic, or a special rule that was not carried over: errors like these look inconspicuous in the target system and often surface only at year-end or in the next audit. A plain reconciliation does not catch them, because it only asks whether two data sets match, not whether the data is correct in business terms.
Reconciliation and a rule-based expected result, in the same run.
SQACE reconciles source and target and additionally computes, from the source data and your rules, what the target system must hold. This separates two questions a simple comparison blurs: was the data migrated cleanly? And was the result already correct in business terms beforehand?
Expected is the second, rule-based calculation from the legacy system's data. Classified as a completeness deviation in the position_count field, tracked across runs.
1. Expected from the source
Compute the expected result
From the legacy system's data and your business rules, SQACE computes what the target system must hold. That is a second, rule-based calculation, not a mere copy.
2. Reconcile old against new
Match source and target
Record, column and total are set against each other: completely, with tolerances and severities. Missing, duplicate and deviating positions stand out.
3. Verdict at field level
Classify deviations
Every deviation is classified down to the field and rule level and explained in business terms, stored in the protected data space and tracked across runs.
Migrations in banking, documented.
SQACE has been in production at LBBW since 2020 as the central platform for data testing. There, the method is built out from 6 productive applications, scaling toward 70 to 80, and it is used in a standardized way across teams.
The same method carries the migration: what can be verified as a reusable rule set checks the move today and the releases that follow tomorrow. The one-off migration test becomes the ongoing verification.
At LBBW, SQACE is the central platform for data testing, from 6 productive applications, scaling toward 70 to 80. The figures shown are documented publicly on sqace.io.
LBBW, public reference (Jens Wauer)
Over 20 years of banking-domain depth (FINARIS, formerly RapidRep). Made in Europe, Frankfurt am Main.
Verify a migration
A plain comparison shows that two data sets match. It does not catch an error that was already in the legacy system. SQACE combines the reconciliation of old against new with a rule-based expected result: it computes the expected business result from the source data and your rules and sets it against the target system.
Yes. The comparison runs at record, column and rule level across large data sets, with tolerances and severities. Deviations are stored in the protected data space and can be analyzed down to the field and rule level.
The rule sets and test building blocks you built for the migration can be reused as a scheduled or CI/CD-triggered suite. The one-off migration test becomes the ongoing release verification.
Secure your migration on real data.
In a demo we verify, on a slice of your migration, that the old and the new deliver the same correct result. Or start with a proof of concept.