61% of migration projects exceed planned timelines by 40 to 100%. The most common cause is not technical complexity. It is the migration strategy itself, specifically, the decision to attempt a big-bang cutover instead of running old and new systems in parallel. Big-bang rewrites succeed only 10 to 25% of the time. Those numbers describe a strategy whose most catastrophic failure mode, discovering that the new system behaves incorrectly only after the legacy has been decommissioned, is also its most common. Dual-run strategies exist to eliminate that failure mode: to produce verified evidence that the modern system behaves equivalently to the legacy before any user depends on it exclusively.
A parallel run is not a testing phase. It is a production-equivalent validation that operates under real production conditions, with real production data, until a defined evidence standard is met. The modern system receives the same inputs as the legacy, produces its own outputs independently, and those outputs are compared at defined intervals with defined tolerance thresholds. The legacy remains the system of record, it serves users, its outputs are authoritative, until the parallel run’s exit criteria are met and the organization has the evidence to support cutover with confidence rather than optimism.
Scope the Parallel Run Correctly
SMART TS XL extracts every COMP-3 field definition so reconciliation tolerances reflect actual field precision, not generic thresholds.
إعرف المزيد…What a Dual-Run Strategy Actually Means
Parallel running is frequently conflated with blue/green deployment, A/B testing, and feature flag rollouts. These are related but distinct:
نشر أزرق / أخضر maintains two identical production environments and switches traffic between them instantaneously. The purpose is zero-downtime deployment, not output validation. The assumption is that the new environment is already correct, it is the same application on different infrastructure. Parallel running makes no such assumption.
إختبار أ / ب deliberately routes different users to different system versions to measure behavioral differences. The purpose is experimentation. Parallel running routes the same inputs to both systems to detect and eliminate differences.
ميزة الأعلام toggle functionality within a single system. Parallel running operates two separate systems simultaneously.
What distinguishes a true parallel run is the output comparison: both systems process the same inputs, and the outputs are compared record by record, aggregate by aggregate, at defined reconciliation intervals. A discrepancy is an investigation trigger, not a user-visible failure. The legacy system’s output is the authoritative result; the modern system’s output is the candidate. The parallel run continues until the candidate’s output matches the authoritative output within defined tolerances consistently enough to meet the exit criteria.
The Three Dual-Run Variants
Not every parallel run looks the same. Three variants serve different risk profiles, cost constraints, and regulatory requirements:
Variant 1: Full Parallel
Both systems process all inputs simultaneously. Every output from both systems is compared. The modern system runs at full production scale alongside the legacy.
التكلفة: Highest. Double infrastructure, double operational monitoring, double support during the run period. Expect 3-6 months minimum; regulated environments with complex portfolios run longer.
الثقة بالنفس: Highest. Every production input exercises both systems; every discrepancy is caught before cutover.
عند الحاجة: Regulated financial services where the system performs calculations that feed regulatory submissions (Basel III capital, IFRS 9 expected credit loss, AML transaction monitoring). DORA’s operational resilience framework requires demonstrating equivalence for critical function changes. OCC guidance for US national banks strongly implies pre-approval validation for core system replacements. In these environments, “we tested in staging” is not a sufficient evidence basis for cutover.
Variant 2: Shadow Mode
The modern system runs behind the legacy, ingesting the same data and producing outputs that are captured and compared, but never served to users. The legacy remains the exclusive system of record for all user-facing operations.
التكلفة: Lower than full parallel. Only one system serves traffic; the modern system’s infrastructure can be sized at a lower tier during shadow mode.
الثقة بالنفس: High for functional equivalence; cannot validate latency and performance under user-facing load.
When appropriate: Batch processing workloads where outputs are files or database writes rather than real-time user responses. Systems where the business consequence of a user encountering a modern system failure is high. Early phases of a longer parallel run, before confidence is sufficient to expose users.
Variant 3: Traffic Splitting
A percentage of real user traffic is routed to the modern system while the remainder stays on the legacy. The split typically progresses: 5% → 10% → 25% → 50% → 100%. A kill switch must redirect all traffic to the legacy within seconds.
التكلفة: Moderate. Infrastructure scales with the traffic percentage.
الثقة بالنفس: Real-user validation under production conditions. Detects latency, error rate, and behavioral issues that shadow mode cannot surface.
خطر: Real users may encounter modern system failures or incorrect outputs before the issue is detected. Appropriate for non-regulated, relatively low-stakes workloads where the cost of user exposure to occasional failures is acceptable and bounded.
Scoping the Parallel Run: What Must Run in Parallel?
The question “what must be in the parallel run?” is answered by the dependency graph, not by the modernization plan.
Running the entire application portfolio in parallel is the most expensive correct answer. Running only the explicitly modernized component is the cheapest incorrect one: it validates the component in isolation while missing every program that depends on its outputs, whose behavior may change as a result of the modernized component’s changes.
The correct scope is the dependency closure of the modernized component:
Modernized component
|
├── Direct dependents (programs that call or consume output of component)
│ └── Transitive dependents (programs that depend on direct dependents)
│
└── Direct dependencies (programs the component calls or reads from)
└── Changed dependencies (those that were also modernized)
Parallel run scope = component + all of the above
A change to a COBOL copybook that defines the customer record layout affects every program that includes the copybook, potentially hundreds. Validating only the one program that was explicitly changed leaves 299 programs running in production against a record layout that is now different without any parallel validation. The discrepancies produced by those 299 programs appear after cutover, not during the parallel run, because those programs were not in the parallel scope.
Parallel migration involves duplicating the environment, which allows testing and comparison. Parallel processes offer reduced risks because users transition to a new system gradually, which ensures continuity and minimizes disruptions. That reduced risk is only real when the scope of what is duplicated covers the full dependency closure. A partial scope produces a false confidence that the parallel run eliminates.
Reconciliation: What to Compare and at What Tolerance
The reconciliation framework answers three questions: what to compare, at what level of granularity, and with what tolerance.
Reconciliation Levels
Multi-level reconciliation covers the full output chain from individual records to aggregate submissions:
| مستوى | What Is Compared | تردد | الغرض الأساسي |
|---|---|---|---|
| القيد | Individual output fields, value by value | Every batch run | Catch field-level discrepancies before they aggregate |
| كيان | All records for a single customer, account, or policy | يوميًا | Catch entity-level inconsistencies invisible at the record level |
| Batch/Period | Totals across a processing run or reporting period | Each batch cycle | Confirm aggregate outputs match before downstream consumption |
| التنظيمية | Outputs that feed regulatory submissions | Each submission cycle | The highest-stakes comparison; must match exactly within defined tolerance |
Record-by-record validation sounds straightforward until teams confront how systems actually produce outcomes. Legacy platforms may generate multiple intermediate files, derived tables, and downstream feeds, while the modern system may consolidate or restructure data into a more normalized model. Achieving that requires careful definition of identity rules, canonical keys, and tolerance boundaries.
The COMP-3 Tolerance Problem
Setting reconciliation tolerances for COBOL-to-modern migrations requires understanding that numeric representation differs between COBOL and modern languages, not because of implementation error, but by design.
لغة كوبول COMP-3 (packed decimal) stores numeric values with exact decimal representation. A value of 12345.67 is stored as exactly 12345.67. Modern languages that use IEEE 754 floating-point arithmetic (double, float) store the same value as the closest binary approximation, which for 12345.67 is 12345.670000000000073....
The reconciliation discrepancy for a field defined as PIC S9(9)V99 COMP-3 (9 digits, 2 decimal places) should be tolerated at the 3rd decimal place, beyond the field’s actual precision, not at a generic percentage threshold that treats a 0.000000000073 difference and a 1.00 difference the same way.
-- Reconciliation query with COMP-3-aware tolerance
-- Field precision: PIC S9(11)V99 COMP-3 = 2 decimal places
-- Tolerance: 0.005 (half a unit at the 3rd decimal place)
SELECT
l.transaction_id,
l.regulatory_amount AS legacy_amount,
m.regulatory_amount AS modern_amount,
ABS(l.regulatory_amount - m.regulatory_amount) AS absolute_diff,
CASE
WHEN ABS(l.regulatory_amount - m.regulatory_amount) = 0
THEN 'EXACT_MATCH'
WHEN ABS(l.regulatory_amount - m.regulatory_amount) <= 0.005
THEN 'WITHIN_PRECISION_TOLERANCE'
WHEN ABS(l.regulatory_amount - m.regulatory_amount) <= 0.01
THEN 'MARGINAL'
ELSE 'DISCREPANCY'
END AS reconciliation_status,
l.batch_date
FROM legacy_regulatory_output l
JOIN modern_regulatory_output m
ON l.transaction_id = m.transaction_id
AND l.batch_date = m.batch_date
WHERE l.batch_date = CURRENT_DATE - 1
AND ABS(l.regulatory_amount - m.regulatory_amount) > 0
ORDER BY absolute_diff DESC;
Every COMP-3 field in the parallel scope requires its own tolerance setting derived from its PIC clause definition. A portfolio with 200 COMP-3 fields across 50 programs requires 200 field-specific tolerance decisions, not a single global threshold applied uniformly.
Reconciliation Cadence
Hourly record count checks across all critical tables. Daily field-level reconciliation on high-transaction domains. Weekly full checksum comparison across every data domain.
For batch-processing environments, the cadence aligns with the batch schedule: every nightly batch run produces a reconciliation report; monthly processing cycles produce a monthly reconciliation; quarterly regulatory submissions produce a quarterly reconciliation.
Exit Criteria: When Is the Parallel Run Complete?
The parallel run ends when the evidence is complete, not when the calendar says so.
The most common parallel run failure is not a technical failure. It is an organizational one: the exit criteria were not defined precisely enough to be enforceable, so they are renegotiated when the parallel run is running long. An exit criterion of “no significant discrepancies for 30 days” that is renegotiated to “no significant discrepancies for 20 days” when day 22 arrives with a non-critical discrepancy has not been met, it has been abandoned.
Exit criteria for non-regulated environments:
- Zero critical discrepancies in the last N consecutive batch cycles (N defined in writing before the parallel run begins)
- Discrepancy rate for non-critical differences below X% for M consecutive cycles
- Performance within defined SLA of the legacy system under equivalent load
- Rollback capability demonstrated in a test exercise, not just documented
- Business owner sign-off on the final reconciliation report
Additional exit criteria for regulated environments:
- Regulatory pre-notification filed where required (DORA: 3-month advance notification for critical function changes; OCC: prior approval for core system replacements in national banks)
- Independent audit of the reconciliation methodology completed and signed off
- Every discrepancy found during the run documented with root cause and resolution, not a count, a log
- Parallel run report in the format acceptable to the relevant regulatory body, reviewed by compliance before cutover is approved
The exit criteria trap: If the exit criteria can be renegotiated after the parallel run starts, they were not exit criteria, they were aspirations. Set them in writing before the run begins, get them signed off by the business owner and compliance, and enforce them without negotiation. A parallel run that ends on calendar rather than evidence has not produced the confidence it promised.
COBOL Branch Coverage: What the Parallel Run Must Actually Validate
A parallel run that processes only typical production inputs validates only typical production behavior. It does not validate what the legacy system does when it receives atypical inputs, the error conditions, the edge cases, the boundary values that correspond to specific EVALUATE branches, specific error handlers, and specific range conditions that normal production traffic may exercise rarely or never.
The cyclomatic complexity of each COBOL program in the parallel scope determines the minimum number of distinct inputs required to cover all independent execution paths. A program with CC = 40 has at least 40 linearly independent paths. If 30-day production traffic covers 15 of them with any regularity, the other 25 are unvalidated, the parallel run has not demonstrated equivalence for those paths. If those paths are exercised after cutover (by a quarterly process, by an unusual customer record, by a specific error condition), they may produce discrepancies that the parallel run never detected.
Static analysis of each COBOL program in the parallel scope produces:
- The CC value, which is the minimum test case count for complete path coverage
- The specific EVALUATE WHEN conditions that correspond to each path
- The IF conditions that require specific boundary-value inputs
- The error handling paragraphs that require injected error conditions to exercise
This analysis converts the parallel run question from “did we run long enough?” into “have we covered all the paths at least once?”, a question that can be answered with evidence rather than probability.
The Cost Model and Duration Planning
Plan for double infrastructure costs for the duration of the parallel run. The range that appears consistently in practitioner experience: 3-6 months for a typical modernization scope, longer for:
- Large dependency closures where hundreds of programs are in the parallel scope
- Regulatory pre-approval processes that add calendar time independent of technical progress
- High discrepancy rates in early weeks that extend the validation horizon before exit criteria can be met
- Batch cycles that occur monthly or quarterly, each cycle must be covered at least once in the parallel run, even if the weekly discrepancy rate is otherwise acceptable
Running two systems simultaneously means double the infrastructure costs, double the monitoring, and the cognitive overhead of your team supporting both. Plan for 3 to 6 months of parallel running.
Minimizing duration without sacrificing validation quality:
Scope to the dependency closure only. Running the full portfolio in parallel when the modernization scope affects 10% of the portfolio triples the infrastructure cost unnecessarily. Scope to what the dependency graph says must be included.
Use shadow mode in early phases. Shadow mode requires less infrastructure and carries less operational risk than full parallel. Running in shadow mode for the first 6-8 weeks while discrepancy rates are highest avoids exposing users to a system that is still being validated.
أتمتة المصالحة. Manual comparison of million-record nightly batch outputs is not viable. Automated reconciliation pipelines that run every batch cycle and produce a discrepancy report without human intervention are the operational foundation that keeps the parallel run from becoming a full-time job for a team of data analysts.
Some enterprises are better served by tighter, well-governed phased migrations rather than open-ended parallel runs. Keeping two estates alive for too long can increase exposure, especially where suppliers, temporary access, and personal data are involved. The parallel run should be as short as the evidence standard allows, not as long as the calendar permits.
كيفية SMART TS XL Supports Accurate Dual-Run Execution
Four specific decisions in a parallel run program are most accurately made from structural evidence rather than from estimates: what to include in the parallel scope, how deeply to test each program, what tolerance to set for each numeric field, and whether anything has changed in the dependency graph before cutover.
SMART TS XLالصورة رسم خرائط تبعية التطبيق produces the dependency closure of every modernized component: every program that depends on it (directly and transitively), every program it depends on, and every dataset that flows between them. This dependency closure is the parallel run scope, derived from the actual code, not from the migration plan’s assumptions about what is connected to what.
استخدم تحليل الكود الثابت capability computes the cyclomatic complexity of every COBOL program in the parallel scope, identifies every EVALUATE branch condition and IF boundary value, and surfaces the specific input conditions required to exercise every execution path at least once. This analysis is what converts “we ran 30 days of production” into “we covered all 40 execution paths in CUSTCALC and all 28 in TRANPROC”, a demonstrably stronger evidence basis.
استخدم تحديث التراث analysis extracts every COMP-3, COMP, and COMP-5 field definition across the parallel scope, providing the precision metadata that reconciliation tolerances must reference. A parallel run with field-specific tolerances derived from the actual PIC clause definitions catches genuine discrepancies and suppresses representation-difference noise, the combination that keeps discrepancy investigation effort focused on real problems.
استخدم تحليل الأثر capability validates the parallel scope in the days immediately before cutover: has anything changed in either system’s dependency graph since the parallel scope was defined? A new COPY statement added to a program during the parallel run period may have introduced a new dependency that was not in the original scope, and that is not covered by the reconciliation that has been running. Impact analysis catches this before cutover, not after.
Run Both Until One Is Ready to Run Alone
The parallel run costs money. Double infrastructure, double monitoring, months of reconciliation effort, and organizational focus divided between supporting the running legacy and validating the emerging modern. None of that cost is waste, it is the cost of the evidence that makes cutover safe.
The exit condition: all thresholds met, final reconciliation report signed off, legacy decommissioned cleanly. That sequence, thresholds met, report signed, decommission clean, is what separates the cutovers that go unnoticed from the ones that make the post-mortem archive. TSB Bank did not run a sufficient parallel validation before 1.9 million customers were locked out. Queensland Health did not validate the full scope of pay rules before 35,000 workers received incorrect paychecks. The evidence that would have changed those outcomes was available. The parallel run that would have produced that evidence was not run to its appropriate exit criteria.
The modern system is ready to run alone when the evidence says so. Not when the timeline says so, not when the budget pressure says so, and not when stakeholder fatigue says so. The parallel run ends when the exit criteria are met. Everything else is a negotiation with risk.
