Modernisation proposal for review; durations are indicative.

Migration and Rollback

Proposal status

This is an unapproved planning proposal for migrating CardDemo toward the architecture described in Target Architecture, using the preservation and resolution decisions in CardDemo Change Mapping. It is not migration authority, a production design, a cutover approval, a staffing or cost commitment, or permission to retire any existing component.

The evidence describes a partial and contradictory reconstruction of a heterogeneous estate. Migration must therefore proceed through independently verifiable slices, with controlled coexistence and an available recovery path. Successful compilation, deployment, record processing, or matching counts alone must not be treated as semantic equivalence.

Confirmed business behaviour, data meanings, interfaces, error distinctions, audit history, data integrity, and customer continuity remain in scope. Contradictory or unsupported behaviour must enter evidence resolution rather than being silently normalized.

Migration principles

Each migration slice must have a bounded capability, known source and target authorities, characterized interfaces, explicit transaction boundaries, measurable reconciliation, tested recovery procedures, and accountable business, data, security, platform, and operational reviewers. Where these conditions cannot be established, the slice remains blocked by missing evidence.

The default approach is reversible migration rather than immediate replacement. Read paths should precede financial or multi-entity writes where dependencies permit. A legacy path must remain available until the replacement has passed agreed production-readiness and parallel-run exit gates. The programme must not assume that every legacy program, file, transaction, or job requires a corresponding Azure service.

For every relevant behaviour or control, the slice plan must record whether it is preserved, intentionally changed, awaiting resolution, or deferred. Confirmed behaviour is preserved unless an explicit change is accepted. Intentional changes require approval through the applicable business, security, data, operational, and change-management processes, which have not yet been identified.

Rollback is preferred where target state and external effects can be safely reversed. Forward recovery is required where completed financial effects, emitted messages, consumed identifiers, audit records, or actions observed by another party cannot safely be undone. Neither strategy is credible until exercised with representative failure conditions.

Preconditions and critical path

The critical path begins with Establish the Deployed Baseline and Evidence Register. The programme must identify active releases, environments, programs, maps, copybooks, jobs, procedures, datasets, VSAM clusters and alternate indexes, database and IMS objects, queues, scheduler definitions, load modules, configurations, generated artifacts, and external consumers. Source-only, generated, optional, inactive, historical, and obsolete material must be distinguished from deployed behaviour.

Accountable owners must be identified for business rules, data, interfaces, security, operations, recovery, and acceptance. Access to representative environments, data, logs, catalogs, scheduler information, executable procedures, and hybrid interfaces is also required. Missing access or ownership is a cutover blocker rather than an assumption to be worked around.

Data authority decisions must classify each representation as authoritative, derived, replicated, synchronized, independently maintained, historical, or obsolete. This applies particularly to customers, accounts, cross-references, cards, transactions, rejected transactions, balances, users, transaction types, categories, authorizations, fraud records, statements, and reports. Canonical modelling must not begin by erasing unresolved differences.

The programme must also establish applicable security, privacy, card-data, residency, retention, audit, accessibility, records-management, Azure landing-zone, software-supply-chain, and change-management requirements. Availability, performance, maintenance windows, outage tolerance, recovery time, recovery point, and retention remain decisions until owners approve measurable thresholds.

The first accepted end-to-end slice is the next re-estimation point. No elapsed duration, staffing requirement, budget, or production outage can be derived from the supplied material.

Characterization and acceptance baseline

Before replacing a path, Characterize Behaviour and Define Acceptance Before Replacement must produce executable tests for its confirmed rules and unresolved variants. Tests should record the environment, input, output, messages, return codes, state before and after execution, ordering, commits, locks, logs, external effects, and recovery outcome.

Coverage must include normal, boundary, invalid, duplicate, concurrent, not-found, partial-failure, restart, rerun, and restoration cases. Relevant paths include sign-on and routing, account and card inquiry and maintenance, user administration, bill payment, accepted and rejected transactions, authorization, fraud, reference-data synchronization, reports, statements, imports, exports, batch sequences, destructive file maintenance, queue failures, deadlocks, and interrupted processing.

Acceptance results must distinguish passed, failed, blocked by missing evidence, not executable, and not applicable. Processing coverage does not establish that calculations, state transitions, messages, ordering, security, or external effects are correct.

Migration waves

Foundation and non-production rehearsal

The foundation wave should establish delivery automation, supported runtime environments, least-privilege identities, secrets management, protected logging, hybrid connectivity, telemetry, deployment controls, backup, restoration, and reconciliation tooling. Azure services remain conditional choices until connectivity, runtime, security, scale, and support prerequisites are confirmed.

Migration tooling may use Azure Database Migration Service, Azure Data Factory, controlled Azure Storage transfer, or custom containerized conversion. Selection must be based on actual source access, encoding, volume, repeatability, downtime, and security requirements. Tool completion does not prove that business relationships, alternate indexes, or legacy access paths were recreated correctly.

At least one full non-production rehearsal must exercise extraction, transfer, transformation, loading, validation, restart, restoration, and cleanup. Additional rehearsals are required whenever results expose unresolved defects or when the production process materially differs. The unexplained IMS child-layout and unload-allocation discrepancy blocks migration of the affected records.

First candidate slice: read-only servicing

Introduce Read-Only Servicing as the First Candidate Slice is the preferred initial candidate, subject to evidence confirming that it is genuinely low-coupling. Account or card inquiry may establish Entra ID integration where suitable, the web presentation path, coexistence adapters, hybrid access, telemetry, reconciliation, and release procedures without introducing financial writes.

The slice must preserve confirmed source authority, keys, cross-reference lookup, not-found distinctions, masking, filtering, paging, sorting, messages, and routing. Conflicting card keys, a possibly omitted account-key component, page sizes, attention-key meanings, snapshots, and presentation-to-storage mappings must be resolved or explicitly excluded.

During coexistence, the target read result should be compared with the authoritative legacy result using approved field-level and semantic comparisons. Sensitive values must not be exposed merely to simplify comparison. Traffic can move progressively only where user identity, routing, and recovery controls support it. Rollback consists of routing users back to the legacy inquiry path and preserving target telemetry and discrepancy records for investigation.

Reference data, identity, and administration

Reference-data distribution may follow once authority, dependencies, versioning, synchronization direction, refresh latency, and consumer inventories are known. A versioned snapshot can support coexistence, but the programme must detect stale or divergent copies and preserve any confirmed restriction on deleting transaction types referenced by categories.

Identity migration must follow Modernize Workforce Identity and Application Authorization and Preserve User Administration While Replacing Credential Handling. Existing security records may contain credentials, routing attributes, authorization data, or a mixture. Legacy passwords must not be copied unless their protection and migration method are demonstrably safe and supported. Reset or staged federation requires explicit approval.

Identity cutover must prove application authorization, ordinary and administrative routing, segregation of duties, session behaviour, audit, support access, and recovery from identity-provider or connectivity failure. Azure role assignments alone are not application authorization. Rollback must not create an account state in which neither the target nor legacy route can authenticate an authorized user.

Servicing updates

Customer, account, cross-reference, and card updates should migrate only after concurrency, compound keys, card uniqueness and mutability, status and expiry rules, deadlock handling, and security-value treatment are resolved. The intended rollback of an account update when the related customer update fails must be preserved through one local transaction or an explicitly accepted compensation design.

A dual-write approach must not be introduced merely for convenience. If coexistence requires writes to more than one system, one authority must be declared and changes must be propagated through a durable, idempotent mechanism with lag and failure reconciliation. Conflicting successful writes must stop cutover expansion until ownership and correction procedures are applied.

Rollback may route new writes back to the legacy authority if target-only writes have been reconciled and safely replayed. Where target writes have already become authoritative, forward recovery through corrected propagation is safer than restoring an older copy and losing accepted changes.

Payments and transaction processing

Establish Atomic and Idempotent Payment Processing and Separate Accepted and Rejected Transaction Outcomes require stricter gates because they affect transactions and balances. Migration must preserve confirmed account-state, confirmation, duplicate-identifier, limit, expiry, insufficient-funds, accepted-versus-rejected, and failure-reason distinctions.

Before cutover, the programme must resolve identifier generation and exhaustion, duplicate semantics, exact posting and balance effects, commit boundaries, reversals, refunds, interest, fees, category balances, restart, and rerun treatment. If transaction creation and balance adjustment share Azure SQL, a local transaction is preferred. If they are separated, durable commands, idempotency keys, state transitions, an outbox, compensation, and reconciliation are required.

Parallel execution must avoid creating two real financial effects. Shadow validation may compare decisions without committing the target effect, or controlled duplication may be used only where one side is prevented from external posting and the comparison remains meaningful. Reconciliation must cover accepted and rejected populations, identifiers, balances, statuses, failure reasons, and external effects.

After a financial cutover, automatic rollback is permitted only if no unaccounted target effect has occurred. Otherwise the system should stop or restrict new work, preserve evidence, determine the authoritative state, and forward-recover through replay, compensation, or controlled data correction. Rejected work must never be counted as successful processing.

Authorization, fraud, and messaging

Authorization migration depends on characterization of MQ correlation, ordering, synchronization, expiry, acknowledgements, retries, duplicate handling, reply timing, and persistence. Azure Service Bus is the default candidate for durable correlated exchanges, but it is not equivalent merely because messages can be transmitted.

The observed possibility of response-before-persistence requires an explicit decision. A transactional outbox changes timing; preserving response-before-persistence requires durable recovery and reconciliation. Rehearsals must inject failures before and after persistence, publication, acknowledgement, timeout, retry, and dead-letter handling.

Fraud remains logically distinct until its lifecycle and relationship to authorization or transaction acceptance are proven. A cutover must not consolidate fraud outcomes or blocking effects by assumption.

Rollback of messaging must account for in-flight and duplicate messages. Queue switching without draining, fencing, correlation control, and replay rules could process the same request twice or lose a response. Where a response has already been issued, forward recovery of missing persistence may be required.

Batch, reporting, and statements

Batch workflows should be rebuilt from verified prerequisites and outcomes rather than copied from job names. Conflicting daily, weekly, and monthly sequences, waits, checkpoints, file opening and closing, destructive operations, and completion signals must be resolved before replacement.

Rehearsals must include interruption around delete, define, unload, reload, replace, and index-build steps. Restart must not duplicate posting, omit records, expose partially loaded data, or leave alternate indexes inconsistent. A recoverable backup or snapshot must be proven by restoration, not merely created.

Reports and statements require reconciliation of content, totals, sorting, dates, formatting, distribution, and applicable retention. Visual similarity alone is insufficient. Cutover should retain access to required historical outputs until the target can reproduce or appropriately preserve them.

Data reconciliation

Every migration execution must retain sufficient source values, transformation outcomes, rejection details, and run context to support audit and diagnosis, subject to data-minimization and sensitive-data controls. Fixed-width framing, encoding, blanks, zeroes, signs, delimiters, precision, overflow, truncation, invalid dates, unknown record types, duplicates, compound keys, sequence continuity, and cross-record relationships must be tested.

Reconciliation should include controlled source, extracted, transformed, loaded, rejected, and duplicate counts. It must also include referential checks, uniqueness checks, status distributions, sequence checks, and applicable financial and balance reconciliation. Count agreement alone is not sufficient where records can be transformed incorrectly.

Differences must be classified as explained and accepted, correction required, blocked by missing evidence, or unresolved. Unresolved differences affecting authoritative keys, financial values, security, customer continuity, or external effects block cutover. Correction procedures must preserve audit history rather than overwrite discrepancies without explanation.

Cutover gates

A slice may enter production only when its deployed baseline and authorities are known; characterization and migration rehearsals have passed; unresolved contradictions are outside scope or explicitly resolved; security and privacy controls are accepted; monitoring and support ownership are assigned; backup and restoration are tested; reconciliation has approved thresholds and owners; rollback or forward recovery has been rehearsed; and affected consumers and operators have an agreed runbook.

The final cutover decision must also account for the business calendar, change freezes, extraction windows, shared test environments, hybrid connectivity, supplier obligations, licensing, maintenance windows, and reviewer availability. These constraints are currently unknown.

During cutover, changes should be fenced or sequenced so that extraction and final synchronization have a defined boundary. Interfaces, schedulers, user routing, and queue producers or consumers must switch in a controlled order. The programme must verify state and external effects before releasing the next step.

Rollback and forward recovery

Each runbook must define the last safe rollback point, authority before and after that point, routing changes, data restoration scope, in-flight work treatment, replay rules, duplicate controls, and evidence to retain. It must identify who can declare failure and who can authorize recovery actions; those roles are not yet supplied.

Application deployment rollback may use the prior supported release where database and contract changes remain compatible. Destructive or non-backward-compatible schema changes require staged expansion and contraction or forward fixes rather than assuming binary rollback.

Data rollback requires a proven restore point plus reconciliation of messages and external effects that occurred after it. Restoring a database without reconciling queues, files, reports, payments, or responses can recreate duplicates or omit accepted work.

Migration jobs must be restartable from a known checkpoint. Reruns must be idempotent or explicitly compensate earlier work. Failed records should remain isolated and traceable without allowing an apparently successful run to conceal omissions.

Retirement conditions

Legacy retirement is a separate decision, not an automatic consequence of target cutover. A component may be retired only when all consumers and external dependencies are identified or formally accounted for; required data and audit history are migrated or retained accessibly; parallel-run exit criteria are met; reconciliation is accepted; target backup and restoration are proven; support and recovery ownership are active; legal and operational retention duties are satisfied; and fallback dependence has ended.

Credentials, queues, scheduler entries, file transfers, datasets, indexes, database objects, load modules, network routes, and privileged access should be removed only through controlled decommissioning. Required evidence and records must remain available according to approved retention rules. Unknown consumers, unresolved discrepancies, untested restoration, or reliance on legacy reports or recovery procedures block retirement.

Scenarios, capacity, and re-estimation

A low-complexity scenario assumes one coherent deployed baseline, established relational authority, bridgeable interfaces, and a low-coupling first slice. A central scenario assumes multiple active representations, mixed synchronous and batch integration, significant characterization, and temporary dual operation. A high-complexity scenario assumes operationally relevant conflicting releases, incomplete runtime evidence, cross-technology transaction boundaries, and prolonged reconciliation or supplier involvement.

Planning must distinguish human effort for analysis, review, security decisions, test design, and acceptance; tool runtime for scans, builds, transformations, and test execution; waiting time for access, environments, extracts, suppliers, governance, and business decisions; and total elapsed calendar time. Scarce reviewers may include business-rule owners, mainframe specialists, data stewards, security authorities, and operations staff, but their availability is unknown.

Contingency is required for unresolved layouts, failed reconciliation, inaccessible dependencies, incompatible environments, and recovery defects. Architecture choices, sequence, capacity assumptions, and estimates should be revised after the first accepted slice and after any rehearsal that invalidates the assumed migration path.

Measures and benefit claims

The first slice should establish collection methods for change lead time, deployment frequency, failed-change rate, recovery time, incidents, unsupported components, vulnerability-remediation age, batch completion reliability, reconciliation differences, duplicate processing, dead-letter volume, restore-test success, access-review completion, latency, and availability where relevant.

For every measure, the baseline, target, owner, data source, sampling period, exclusions, and review cadence remain to be agreed. No reliability, security, cost, speed, or supportability benefit should be claimed until those elements exist and measurements demonstrate the outcome.