Modernisation plan

CardDemo Modernisation Plan

Proposal status

This document is an unapproved planning proposal for modernising CardDemo on Microsoft Azure. It does not approve architecture, funding, staffing, schedule, outage, production release, service levels, migration, retirement, or claimed benefits.

The supplied material supports a partial source-level reconstruction, not a verified end-to-end production system. It references COBOL, CICS, BMS, VSAM, sequential files, JCL and batch utilities, with possible DB2, IMS, MQ, assembler, REXX, file-transfer, UNIX and scheduler components. It does not establish that all components belong to one release or environment, are active, compile or execute together, or remain production-relevant. Processing, catalog and artifact coverage must not be treated as semantic completeness.

Purpose and intended outcomes

The purpose is to preserve material CardDemo capabilities while creating a supported platform for safer, smaller changes, controlled coexistence, stronger recovery, least-privilege security and improved operational visibility. The plan also seeks to reduce unsupported-technology and key-person dependency, but no cost, reliability, security or delivery benefit may be claimed until a baseline and measurement method exist.

Candidate outcome measures are 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 every adopted measure, the baseline, approved target, accountable owner, source, sampling period, exclusions and review cadence must be established. The first accepted slice should automate collection where practical. Historical counts or lateness observations are not valid baselines until their period, workload, collection method and current relevance are verified.

No cost baseline is supplied. Any later financial case should use agreed formulas rather than claimed savings. For example, annual change-effort difference may be calculated as the validated baseline effort per comparable change minus measured target effort, multiplied by comparable annual change volume and approved loaded effort rate. Avoided incident cost requires validated incident frequency, duration, business impact and response cost. Platform total cost must include Azure consumption, licences, connectivity, support, migration, dual operation, security, testing, data retention and decommissioning; none of these values is currently established.

Evidenced capabilities and behavior to preserve

Observed or described capabilities include sign-on and administrative or ordinary-user routing; account, customer and card inquiry and maintenance; card search, filtering and paging; bill payment; accepted and rejected transaction processing; user administration; authorization and fraud-related processing; transaction-type and category administration; reports and statements; migration; and extensive batch, build, backup and file-maintenance activity.

Confirmed behavior should be preserved unless accountable business and control authorities explicitly approve a change. This includes evidenced validation, not-found and error distinctions, routing, messages, sorting, paging, rejection reasons, duplicate handling, data meanings, exact state changes, ordering and external effects.

Account inquiry appears read-only and uses cross-reference information. Account maintenance compares submitted and previously retrieved values and appears to protect against concurrent updates. A customer-update failure following an account update is intended to cause rollback. Card paths include filtering, detail retrieval, paging and updates to customer information, active status and expiry data.

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. Accepted and rejected transactions must remain distinguishable, with rejection reasons retained and rejected work excluded from successful processing.

Authorization may consume correlated MQ requests, evaluate account, card, customer, balance or credit information, issue approval or decline responses and persist summary and detail records. Fraud processing may have a distinct lifecycle and must remain logically separate until evidence proves otherwise. Reports and statements must be accepted through content and data reconciliation, not visual similarity alone.

Unresolved contradictions must not be silently normalized. These include card keys and update scope, page sizes and attention-key meanings, map and transfer identities, customer layouts and record lengths, transaction-file roles, authorization layouts, FTP direction, batch ordering, active-card counts and whether DB2, IMS, MQ, VSAM and batch components operate together.

Scope and exclusions

The proposed scope includes estate discovery, executable characterization, data-authority decisions, target architecture validation, migration rehearsals, coexistence adapters, security and operational controls, incremental replacement, reconciliation, recovery testing and controlled retirement decisions.

Audit history, data integrity, customer continuity, accepted and rejected outcomes, sensitive-data handling, reports, backups, external effects and legacy recovery dependencies remain in scope for review.

This plan excludes any presumption that every legacy program becomes a service, every store should be consolidated, every discovered component is active, or every job should be copied. It does not select production sizes, commit to dates or staffing, establish regulatory scope, approve password migration, authorize storage of CVV-like data, or permit legacy retirement.

Proposed target architecture

The recommended style is a modular, domain-oriented platform with explicit transactional boundaries and a small number of independently deployable components. Further decomposition should occur only where independent scale, release cadence, security isolation, availability or ownership is demonstrated.

A web presentation layer should replace CICS and BMS paths incrementally while preserving confirmed validation, routing, messages, paging, sorting and error distinctions. Azure App Service is the preferred initial option for conventional web applications and APIs. Azure Container Apps is a credible alternative for containerized workers, mixed runtimes or event-driven scaling. Azure Kubernetes Service should be deferred unless Kubernetes-level control is demonstrably required. Azure API Management may protect and observe broadly consumed APIs but need not front every internal call.

A temporary anti-corruption layer should bridge CICS, commareas, files, MQ, DB2, IMS and VSAM during coexistence. It must translate contracts without silently changing keys, lengths, encodings, status values, directions or error meanings.

Identity and access

Microsoft Entra ID is the preferred workforce identity provider where the population and organizational model permit it. Managed identities should authenticate workloads, while application authorization remains explicit and auditable. Azure role assignments alone are not a replacement for business permissions.

Legacy security records may contain credentials, routing attributes, authorization data or a mixture. Their authority, password representation, RACF relationship and user-type semantics must be resolved. Legacy passwords must not be copied unless their protection and migration method are demonstrably safe and supported. Otherwise, controlled reset or staged federation requires approval.

Servicing data and transactions

A servicing component should support customer, account, cross-reference and card workflows while keeping their meanings and authorities distinct. Azure SQL Database is the leading 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 should be deferred where partition and transaction boundaries complicate cross-entity consistency. PostgreSQL on Azure remains possible, but current evidence does not justify the dialect and support change.

Account and customer changes intended to roll back together should use one local transaction or an explicitly approved compensation design. Card key composition, identity mutability, uniqueness, lock scope, retry behavior and CVV-like value treatment must be resolved first.

Payments and transaction outcomes

Transaction creation and balance adjustment should use a local database transaction when they share a store. If later separated, the design should use durable commands, idempotency keys, explicit states, an outbox, compensation and reconciliation rather than assuming distributed transactions.

Accepted and rejected outcomes should remain independently identifiable. Calculations for balances, limits, interest, fees, discounts, reversals, refunds and category balances must not be implemented from inference.

Messaging, authorization and fraud

Azure Service Bus is the leading candidate for durable commands and correlated request or response exchanges requiring acknowledgements, retries, duplicate detection and dead-letter handling. Event Hubs is suitable only for demonstrated streaming and replay needs; Event Grid is suitable for lightweight notification rather than transactional request handling.

The apparent response-before-persistence behavior requires an explicit decision. A transactional outbox improves coupling between persistence and publication but may alter observable response timing. Preserving response-before-persistence requires durable recovery and reconciliation. Neither option is equivalent until ordering, correlation, expiry, synchronization, acknowledgement and failure behavior are characterized.

Batch, reporting and data movement

Batch workflows should be reconstructed from dependencies, checkpoints, completion signals, rerun rules and business outcomes rather than job names. Azure Data Factory is a candidate for scheduled movement and transformation, Azure Functions for bounded event-driven work, and Azure Container Apps jobs for longer-running executables. Durable Functions should be used only where its replay model fits. Azure Batch is deferred until parallel-compute demand is demonstrated.

Reporting should be separated from online writes where practical. Relational read facilities, controlled extracts and Azure Data Lake Storage are credible options. Microsoft Fabric or Azure Synapse Analytics should be considered only if scale, governance, transformation and support requirements justify them.

Data migration and reconciliation

Every significant representation must be classified as authoritative, derived, replicated, synchronized, independently maintained, historical or obsolete before canonical modelling. This applies to customers, accounts, cards, cross-references, transactions, rejected transactions, balances, categories, transaction types, users, authorizations, fraud records, reports, statements, migration data and backups.

Migration must preserve meaningful distinctions in compound keys, blanks, zeroes, signs, encodings, dates, precision, physical layouts, status meanings, alternate indexes and access paths. It must test framing, delimiters, truncation, overflow, invalid dates, unknown records, duplicates, sequence continuity and cross-record relationships.

Azure Database Migration Service, Data Factory, controlled Azure Storage transfer and custom containerized converters are credible options. Selection depends on verified connectivity, encoding, volume, downtime, security and repeatability. Tool completion or matching counts alone does not prove semantic correctness.

Each rehearsal must produce controlled counts, rejected-record details, referential and uniqueness checks, status distributions, applicable financial reconciliation and restart evidence. The discrepancy between an IMS child layout and unload allocation must be resolved before affected records are transformed.

Security, reliability and operations

The proposal is to use Entra ID, managed identities, Azure role-based access control, Key Vault, encryption, private connectivity where justified, network segmentation, restricted outbound access and protected logging. Passwords, card-security values, unnecessary personal information and unnecessary message payloads must not be logged.

Azure Monitor, Application Insights, Log Analytics and service-native metrics should correlate activity across applications, databases, queues, workflows, migration batches and coexistence adapters. Operational ownership must cover deployment, patching, access review, secret rotation, incident response, dead-letter recovery, data correction, reconciliation, capacity, backup and restoration.

Backup creation is not sufficient. Recovery must include tested restoration and reconciliation across databases, messages, files, indexes, reports and externally observed effects. Availability, latency, throughput, retention, residency, maintenance windows, outage tolerance, recovery time and recovery point objectives remain business and architecture decisions.

Delivery plan and gates

Delivery should proceed through narrow, reversible slices:

1. Establish the deployed and measurable baseline, evidence register, characterization suite and measurement definitions.
2. Resolve data authority and rehearse migration and reconciliation.
3. Deliver a reversible read-only account or card inquiry path, if evidence confirms that it is low-coupling.
4. Modernise workforce identity and user administration.
5. Establish authoritative reference data and servicing updates.
6. Cut over payments and accepted or rejected transaction outcomes.
7. Migrate authorization, fraud, batch, reporting and recovery capabilities.

The supplied delivery planning record provides low, central and high elapsed-working-day scenarios for these slices. These ranges are planning scenarios rather than commitments and conflict with the broader conclusion that no elapsed duration is yet supportable. They should therefore be used only for comparative sequencing and contingency until access, owners, environments and the first accepted slice provide evidence for re-estimation.

The critical path starts with environment access, active-release identification, owner assignment, data-authority and interface decisions, representative test data and executable characterization. It then runs through the first accepted end-to-end slice and re-estimation.

Each slice must define human analysis and approval effort, agent or tool runtime, waiting time and total elapsed time separately. Likely scarce reviewers include business-rule owners, mainframe specialists, data stewards, security authorities, operations staff and interface owners. Shared environments, hybrid connectivity, extract windows, supplier participation, licences, release windows, business calendars and change freezes remain unknown constraints.

A slice must not enter build until its applicable business rules, data authority, interfaces, security duties, acceptance tests and recovery approach are defined. It must not enter production until migration and coexistence are rehearsed, reconciliation and failure testing pass, operational ownership and runbooks are accepted, and rollback or forward recovery is viable.

Acceptance and preserved-control decisions

Acceptance must classify results as passed, failed, blocked by missing evidence, not executable or not applicable. Tests must verify exact state changes, errors, messages, ordering, duplicates, concurrency, rollback, idempotency, restart, rerun, reconciliation, authorization, audit, restoration and external effects.

Financial cutover requires failure injection around transaction creation, balance adjustment, state change, publication, acknowledgement and commit. No unexplained authoritative financial difference, duplicate real effect or unaccounted external effect is acceptable.

Legacy retirement remains deferred until all consumers, retained records, recovery dependencies, external obligations and parallel-run exit criteria are confirmed. Any intentional change to confirmed behavior requires explicit approval.

Principal unresolved decisions and risks

Immediate decisions are required on the deployed baseline, data and balance authority, keys and compound identities, transaction boundaries, identity and authorization model, regulatory and card-data obligations, interface semantics, batch dependencies, retention, service levels, recovery objectives and accountable ownership.

Material risks include replacing the wrong release; lost or partial updates; incorrect balances; duplicate processing; unsafe replay; stale reference data or indexes; changed authorization timing; omitted consumers; malformed data conversion; prohibited sensitive-data retention; ineffective permissions; and restoration that leaves messages or downstream effects inconsistent.

Contingency must be retained for inaccessible runtime evidence, conflicting releases, unresolved layouts, failed reconciliation, unavailable interfaces, supplier delay and recovery defects. Unsupported claims remain deferred rather than assumed absent, and successful compilation, deployment, migration or processing must never be treated by itself as evidence of behavioral equivalence.