Modernisation proposal for review; durations are indicative.

CardDemo Change Mapping

This document is an unapproved planning proposal. It maps evidenced capabilities and requirements to proposed preservation, change, resolution, or deferral decisions. It does not establish complete estate coverage, approve an Azure design, authorize migration or retirement, or demonstrate semantic equivalence. Confirmed behaviour should be preserved unless an explicit change is accepted; contradictions and unsupported claims require evidence resolution rather than normalization.

CHG-001 Establish the Deployed Baseline and Evidence Register

The supplied material supports only a partial reconstruction spanning COBOL, CICS, BMS, VSAM, sequential files, JCL, batch utilities, and possible DB2, IMS, MQ, assembler, REXX, file-transfer, UNIX, and scheduler components. The proposed decision is to resolve which releases, environments, programs, maps, copybooks, jobs, procedures, datasets, indexes, database objects, queues, load modules, configurations, and external interfaces are active before behavioural replacement begins.

The target is an accountable inventory that distinguishes confirmed runtime behaviour, source-only evidence, generated artifacts, optional or inactive capability, contradictions, unavailable evidence, and obsolete material. It depends on access to deployed environments, scheduler and catalog information, executable procedures, logs, representative data, and business and operational owners. Runtime connectivity, ownership, active releases, and production relevance remain uncertain; processing or catalog coverage must not be treated as semantic completeness.

CHG-002 Characterize Behaviour and Define Acceptance Before Replacement

Observed capabilities include sign-on, role routing, servicing, card functions, payment, transaction processing, user administration, authorization, fraud processing, reference-data administration, reporting, statements, migration, and batch operations. The proposed decision is to preserve confirmed rules, messages, state changes, ordering, errors, and external effects, while resolving contradictions through executable characterization. Unsupported behaviour is deferred rather than assumed absent.

The target is a repeatable characterization and acceptance suite recording environment, inputs, outputs, messages, return codes, data changes, commits, logs, external effects, and recovery outcomes. Acceptance must distinguish passed, failed, blocked by missing evidence, not executable, and not applicable. It must test duplicates, concurrency, rollback, idempotency, restart, rerun, reconciliation, authorization, audit, restoration, and partial failure. This depends on representative environments, controlled test data, interface access, and scarce review by business-rule owners, mainframe specialists, data stewards, security authorities, and operations staff. Current test coverage and executable availability are unknown.

CHG-003 Modernize Workforce Identity and Application Authorization

Sign-on validates security data and routes users according to an administrative or ordinary-user indicator. The proposed decision is to preserve confirmed sign-on outcomes and routing distinctions, change the implementation toward Microsoft Entra ID where the workforce and organizational model permit it, and resolve the authority of existing security records, password representation, user-type semantics, RACF relationships, and effective permissions.

The target is platform authentication through Entra ID, managed identities for workloads, and explicit application authorization with auditable separation between ordinary servicing, user administration, operational support, and security administration. Legacy passwords must not be copied unless their protection and migration method are demonstrably safe and supported; otherwise reset or staged federation requires approval. Retry limits, lockout, session duration, step-up authentication, break-glass access, deletion policy, identity propagation, and privileged-access standards remain unresolved. Azure role assignments alone will not satisfy application authorization requirements.

CHG-004 Replace CICS and BMS Presentation Incrementally

The evidence describes menu validation, program transfers, maps, paging, attention keys, messages, and administrative or ordinary-user routing, but inventories and contracts conflict. The proposed decision is to preserve confirmed validation, routing, error distinctions, sorting, paging, and user-visible messages. Page sizes, PF-key meanings, map identities, transfer targets, unavailable options, and placeholder treatment must be resolved before replacement.

The target is an incrementally introduced web presentation layer and APIs, initially hosted on Azure App Service where a conventional managed web runtime fits. Azure Container Apps remains an alternative for container portability, workers, or mixed runtimes; Azure Kubernetes Service is deferred unless Kubernetes-level control is demonstrated as necessary. A temporary anti-corruption layer should translate CICS, commarea, file, MQ, DB2, IMS, and VSAM contracts without silently changing lengths, keys, encodings, statuses, or errors. Accessibility and enterprise interface standards remain unknown.

CHG-005 Introduce Read-Only Servicing as the First Candidate Slice

Account inquiry retrieves account and customer details through cross-reference information without modification. Card inquiry includes filtering, listing, detail retrieval, and paging. The proposed decision is to preserve those confirmed read behaviours and consider a narrow account or card inquiry path as the first accepted slice, provided source authority, keys, masking, paging, and response semantics are first resolved.

The target is a reversible, observable path that establishes identity, hybrid connectivity, delivery automation, telemetry, reconciliation, and acceptance without introducing financial writes. It depends on an authoritative deployed baseline, representative data, access approval, and a coexistence adapter. Conflicting card keys, omitted account-key components, page sizes, snapshots, and presentation-to-storage mappings remain uncertainties and may prevent this slice from being low risk.

CHG-006 Consolidate Party, Account, and Card Servicing Transactions

Account maintenance validates submitted values against previously retrieved values and appears to use locking or concurrent-update detection. A customer-update failure after an account update is intended to cause rollback. Card maintenance validates names, numeric fields, lengths, status, and expiry information. The proposed decision is to preserve confirmed validation, not-found distinctions, concurrency protection, and intended rollback behaviour.

The target is a servicing component that keeps customer, account, cross-reference, and card meanings distinct while allowing an initial shared deployment. Azure SQL Database is the leading data candidate where relational constraints, optimistic concurrency, and local compound transactions fit the recovered semantics. Azure SQL Managed Instance remains credible if compatibility or instance-level features are required. Azure Cosmos DB is deferred because partition and transaction boundaries may conflict with cross-entity consistency; PostgreSQL on Azure remains an unsupported choice until dialect and operational benefits are established.

Lock scope, deadlock handling, retries, card uniqueness, card identity mutability, compound keys, update scope, and CVV-like value treatment must be resolved. Account and customer changes must use one local transaction or an explicitly approved compensation model.

CHG-007 Preserve User Administration While Replacing Credential Handling

User maintenance can list, add, update, and delete fixed-format records and handles some duplicate, missing-record, required-field, and browse-boundary conditions. The proposed decision is to preserve confirmed administration outcomes and user-visible errors, while changing credential storage and verification only after security assessment. Display masking is not evidence of secure password storage.

The target is auditable user and access administration integrated with the chosen identity model. Permissions, user-type enforcement, deletion policy, concurrent changes, password migration, audit history, and segregation of duties require resolution. The change depends on the identity decision and confirmation of whether legacy user records are authoritative credentials, routing profiles, authorization records, or a mixture.

CHG-008 Establish Atomic and Idempotent Payment Processing

Bill payment is intended to reject blank or unknown accounts, invalid or non-payable states, non-positive or insufficient balances, duplicate transaction identifiers, invalid input, and unconfirmed payment. A valid payment creates a transaction and changes an account balance. The proposed decision is to preserve those confirmed rules and error distinctions while resolving identifier generation, uniqueness, exhaustion, concurrency, and commit boundaries.

The target is a defined atomicity model. Where transaction creation and balance adjustment share Azure SQL, a local database transaction is preferred. If later separated, durable commands, idempotency keys, state transitions, an outbox, compensation, and reconciliation are required rather than assumed distributed transactions. Exact balance effects, duplicate semantics, rollback behaviour, and recovery after partial writes remain uncertain and must be characterized before financial writes are cut over.

CHG-009 Separate Accepted and Rejected Transaction Outcomes

Transaction processing validates accounts, cards, references, limits, expiry, formats, and duplicates. Accepted work is posted or recorded; rejected work should retain failure reasons and must not count as successful processing. The proposed decision is to preserve that distinction and resolve the complete processing chain because similarly named components provide conflicting evidence about substantive writes.

The target is a transaction-processing boundary with explicit accepted, rejected, pending, reversed, and other confirmed states. Rejected records must remain independently identifiable. Retention, privacy, replay eligibility, calculations, interest, fees, discounts, category balances, reversals, refunds, status transitions, and rerun treatment are unresolved. Replacement depends on recovered posting rules, authoritative balances, exact commit boundaries, and reconciliation criteria.

CHG-010 Reconcile Authorization Messaging and Persistence

Authorization may consume correlated MQ requests, evaluate account, card, customer, balance, or credit information, publish approval or decline responses, and persist summary and detail data. Evidence suggests a response may precede IMS persistence and MQ operations may lack synchronization. The proposed decision is to preserve confirmed outcomes, correlation, expiry, and timing only after characterization; cross-technology atomicity must not be assumed.

The target candidate is Azure Service Bus for durable commands and correlated exchanges requiring acknowledgements, retries, duplicate detection, and dead-letter handling. Event Hubs is reserved for demonstrated stream and replay needs, while Event Grid is limited to lightweight notifications. A transactional outbox would couple persistence and publication but could alter response timing. Preserving response-before-persistence would require durable recovery and reconciliation. Existing ordering, reply timing, queue configuration, expiry, synchronization, and failure semantics remain unresolved.

CHG-011 Keep Fraud Processing Logically Distinct

Fraud processing may insert or update records following duplicate-key conditions, but its criteria, lifecycle, purge rules, review process, and relationship to transaction acceptance are not established. The proposed decision is to defer consolidation with authorization and preserve any confirmed separate records or outcomes.

The target is a logically distinct fraud capability until evidence proves a shared lifecycle. State transitions, duplicate handling, blocking effects, operational review, retention, and purge predicates require resolution. No target automation or decision model should be selected from the current evidence alone.

CHG-012 Establish Authoritative Reference Data and Distribution

Transaction types and categories may be administered in DB2 while processing consumes VSAM or sequential extracts. Categories may prevent deletion of referenced transaction types. The proposed decision is to preserve confirmed referential restrictions and resolve whether the capability is active, which store is authoritative, and how runtime copies are synchronized.

The target is one authoritative reference-data store with versioned distribution and controlled read-optimized snapshots where coexistence requires them. Synchronization direction, refresh latency, effective dating, divergence handling, rollback, rerun behaviour, and runtime enforcement remain unknown. Consolidation depends on active-environment evidence and consumer inventories.

CHG-013 Rebuild Batch Workflows from Dependencies Rather Than Job Names

Observed batch activity includes posting, reporting, statements, interest, fees, reference-data movement, authorization loads and unloads, expiry cleanup, backups, file initialization, index construction, migration, date conversion, compilation, deployment, and restoration. Daily, weekly, and monthly sequences conflict. The proposed decision is to preserve confirmed business outcomes but resolve prerequisites, ordering, checkpoints, completion signals, rerun rules, and destructive operations instead of copying jobs one-for-one.

The target is explicit, observable orchestration. Azure Data Factory is a candidate for scheduled movement and transformation; Azure Functions for bounded event-driven steps; Azure Container Apps jobs for longer-running executables; and Durable Functions only where replay semantics fit. Azure Batch is deferred unless parallel-compute demand is demonstrated. No delete, redefine, replace, unload, reload, or index rebuild should be replaced before interrupted-run and recovery behaviour is tested.

CHG-014 Preserve Reports and Statements Through Data Reconciliation

Reports and statements are evidenced, but definitions, totals, dates, formatting, distribution, sorting, and legal retention are incomplete. The proposed decision is to preserve confirmed content and reconciliation outcomes rather than visual similarity alone.

The target is reporting separated from online write paths where practical, using controlled extracts, relational read facilities, or Azure Data Lake Storage subject to classification and retention. Microsoft Fabric or Azure Synapse Analytics is deferred until scale, transformation, governance, and support requirements justify it. Acceptance depends on reconciliation to authoritative transactions and balances and on resolution of distribution and retention obligations.

CHG-015 Resolve Data Authority Before Canonical Modelling

Customers, accounts, cards, cross-references, transactions, rejected transactions, categories, balances, users, authorizations, fraud records, and other domains appear across files, VSAM, DB2, IMS, MQ messages, commareas, and generated outputs. The proposed decision is to resolve each representation as authoritative, derived, replicated, synchronized, independently maintained, historical, or obsolete before defining canonical models.

The target is a model that preserves meaningful distinctions in keys, formats, dates, monetary values, signs, blanks, zeroes, encodings, and status meanings. The relational and IMS authorization representations and the IMS child-layout versus unload-allocation discrepancy require explicit reconciliation. Canonicalization must not erase contradictions for implementation convenience.

CHG-016 Build Rehearsable Migration and Reconciliation Pipelines

Migration and import flows appear to split multi-record exports into customer, account, card, and transaction outputs, but layouts and controls are incomplete. The proposed decision is to preserve source values and transformation outcomes as needed for audit and reconciliation, while resolving framing, encoding, sequence, unknown-record, count, checksum, relationship, and index-recreation rules.

The target is repeatable migration using an evidence-based choice among Azure Database Migration Service, Data Factory, controlled Azure Storage transfer, and custom containerized conversion. Each execution must produce controlled counts, rejected-record details, referential checks, applicable financial reconciliations, and restart evidence. Tool completion does not prove that alternate indexes or access paths were recreated correctly.

CHG-017 Apply Least-Privilege Security and Sensitive-Data Controls

The estate includes credentials, passwords, card data, CVV-like values, customer information, RACF references, datasets, queues, FTP, and administrative paths. The proposed decision is to change platform controls toward Entra ID, managed identities, Azure role-based access control, Key Vault, encryption, network segmentation, and protected logging, while preserving confirmed application authorization and audit obligations.

The target uses private connectivity, restricted outbound access, firewalls, and controlled hybrid links where requirements justify them. Passwords, card-security values, sensitive personal data, and unnecessary payloads must be excluded from logs. Regulatory scope, residency, retention, customer-managed key requirements, effective legacy permissions, ExpressRoute or VPN choice, and security-operations integration remain unresolved. Sensitive-looking fields do not prove populated sensitive content or exposure.

CHG-018 Introduce End-to-End Observability and SRE Operations

Current evidence does not establish monitoring, restart safety, ownership, service levels, or useful recovery. The proposed decision is to add correlated telemetry without claiming reliability improvement until baselines exist.

The target uses Azure Monitor, Application Insights, Log Analytics, and service-native metrics across applications, databases, queues, workflows, migration batches, and coexistence adapters. Ownership must cover deployment, patching, access review, secret rotation, incidents, dead letters, data correction, reconciliation, capacity, backup, and restoration. Availability, latency, throughput, maintenance windows, support arrangements, and escalation routes remain decisions.

CHG-019 Prove Backup, Restore, and External-Effect Recovery

Backup generations and restoration-related work are described, but retention, recoverability, and reconciliation are unknown. The proposed decision is to preserve applicable records and recovery obligations while changing from backup creation alone to tested restoration and reconciliation.

The target defines backup scope, point-in-time recovery, justified geo-recovery, restore testing, and treatment of messages or external effects outside database recovery. RTO and RPO are business decisions and cannot yet be stated. This change depends on authoritative data, interface semantics, retention duties, and assigned recovery ownership.

CHG-020 Automate Supported Build, Release, and Rollback Paths

Observed builds include precompilation, compilation, binding, link-editing, map generation, replacement, and security or catalog changes, with uncertain conditional logic and versions. The proposed decision is to replace fragile promotion mechanics with version-controlled application and infrastructure pipelines while preserving required generated artifacts and deployment dependencies during coexistence.

The target includes repeatable environments, policy and security scanning, database migration controls, progressive deployment, and rollback or forward recovery. Azure landing-zone, naming, tagging, software-supply-chain, accessibility, records-management, and change-management standards must be identified. Compilation or deployment success alone is not acceptance evidence.

CHG-021 Deliver Incrementally with Controlled Coexistence and Retirement

The proposed decision is to change through narrow, independently verifiable slices rather than a single replacement. Candidate later slices include reference-data distribution, access migration, servicing updates, rejected-transaction recording, payment, posting, reporting, authorization, fraud, and batch replacement. This order is provisional and may change with evidence and dependency discovery.

Each slice requires characterization, explicit preserve/change/resolve/defer decisions, coexistence adapters, migration rehearsal, reconciliation, failure injection, recovery procedures, runbooks, and production-readiness review. Retirement is deferred until consumers, retained records, recovery needs, parallel-run exit criteria, and external dependencies are confirmed.

CHG-022 Establish Measures Before Claiming Benefits

The business objective is to reduce change cost, risk, lead time, unsupported technology, and dependency while improving reliability, recoverability, security, supportability, and visibility. The proposed decision is to defer benefit claims until measurable baselines and approved targets exist.

Candidate indicators include change lead time, deployment frequency, failed-change rate, recovery time, incident rate, unsupported-component count, vulnerability-remediation age, batch completion reliability, reconciliation differences, duplicate-processing rate, dead-letter volume, restore-test success, access-review completion, latency, and availability. For each, the baseline, target, owner, source, sampling period, exclusions, and review cadence must be established during the first accepted slice.

CHG-023 Plan Capacity, Scenarios, and Re-Estimation Without Invented Commitments

No deadline, budget, staffing level, outage allowance, or elapsed duration is supported. The proposed decision is to defer commitment and plan low, central, and high-complexity scenarios. The low scenario assumes one coherent baseline and limited dependencies; the central scenario assumes multiple representations and temporary dual operation; the high scenario assumes relevant conflicting releases, incomplete runtime evidence, cross-technology transactions, and prolonged reconciliation or supplier involvement.

The critical path begins with baseline identification, access, owners, authority and interface decisions, executable characterization, and representative environments and data. It proceeds through the first accepted end-to-end slice and re-estimation. Planning must distinguish human effort, agent or tool runtime, waiting time, and elapsed time. Business calendars, freezes, extract windows, licensing, supplier obligations, shared environments, connectivity, and reviewer availability remain unknown. Contingency is required for unresolved layouts, failed reconciliation, unavailable dependencies, and recovery defects.