Modernisation proposal for review; durations are indicative.

Target Architecture

Proposal status and architectural intent

This is an unapproved planning proposal for modernising CardDemo on Microsoft Azure. It is not a production design, migration commitment, acceptance decision, retirement authority, cost estimate, staffing plan, or assurance that the reconstructed estate is complete.

The target architecture should preserve confirmed business behaviour while enabling smaller releases, controlled coexistence, stronger recovery, least-privilege security, supported technology lifecycles, and improved operational visibility. Contradictory or unsupported behaviour must remain unresolved until evidence-resolution and characterization work determines the applicable rule. Successful processing or compilation alone must not be treated as semantic equivalence.

The recommended architectural style is a modular, domain-oriented platform with explicit transactional boundaries and a small number of independently deployable components. It should not begin with a service for every legacy program, transaction, file, or job. Further decomposition is justified only where a domain requires independent scaling, release cadence, security isolation, availability, or ownership.

Availability, recovery time, recovery point, latency, throughput, retention, residency, peak-volume, outage allowance, and maintenance-window requirements are unknown. They are architecture decisions to be agreed before production service selection and sizing.

Proposed domain boundaries

Identity and workforce access

This boundary should authenticate workforce users, establish sessions, and provide administrative or ordinary-user routing. Microsoft Entra ID is the preferred identity provider where the user population and organizational access model permit it. Azure role assignments alone are not a substitute for application authorization.

The existing security records may represent application users, routing attributes, credentials, or authorization data. Their authority, password representation, user-type semantics, deletion policy, and relationship to RACF must be established before migration. Legacy passwords must not be copied into a new identity system unless their protection and migration method are demonstrably safe and supported. Where direct password migration is not possible, a controlled reset or staged federation approach requires business and security approval.

Application roles and permissions should be enforced in the application and recorded in auditable policy, with segregation between user administration, ordinary servicing, operational support, and security administration. Retry limits, lockout, session duration, step-up authentication, break-glass access, and privileged-access standards remain decisions.

Party, account, and card servicing

A servicing component should own customer, account, cross-reference, and card inquiry and maintenance workflows. These concepts may share a deployment initially, but their data meanings and authorities must remain distinct.

The component must preserve confirmed validation, not-found distinctions, account inquiry behaviour, card filtering and paging, status and expiry handling, and concurrent-update protection. Account and customer changes that are currently intended to roll back together require either one local transaction or an explicitly accepted compensation design. The unresolved account component of the card key, card identity mutability, uniqueness, page sizes, attention-key meanings, and treatment of card-security values must be resolved before the corresponding paths are replaced.

Azure SQL Database is the leading candidate where relational constraints, compound transactions, optimistic concurrency, and auditable updates fit the recovered semantics. Azure SQL Managed Instance is a credible alternative if compatibility, instance-level features, or migration tooling require it. Azure Cosmos DB should not be selected merely for scale: its partitioning and transactional scope could complicate cross-entity consistency. PostgreSQL on Azure is also credible, but adopting it would introduce a database-dialect and operational-support choice not justified by current evidence.

Sensitive card and customer fields should be minimized, classified, encrypted, and masked according to confirmed regulatory and business requirements. CVV-like data needs specific review; the proposal does not assume that storing it is permitted.

Payments and transaction processing

A transaction-processing boundary should validate and record accepted and rejected transactions. Bill payment may use this boundary but should retain its evidenced account-state, balance, confirmation, duplicate-identifier, and insufficient-funds rules.

Accepted transaction creation and balance adjustment must have a defined atomicity model. If they reside in one database, a local transaction is preferred. If later decomposition separates them, the design should use durable commands, idempotency keys, an outbox, state transitions, and reconciliation rather than assuming distributed transactions. Identifier generation, duplicate semantics, limits, expiry checks, posting calculations, reversals, refunds, interest, fees, discounts, category balances, and rerun treatment remain unresolved.

Rejected transactions should remain distinguishable from accepted transactions and retain failure reasons. Their retention, privacy treatment, reporting use, and replay eligibility require decisions. A replacement must demonstrate that rejected work is not counted as successful processing.

Authorization and fraud

Authorization should be treated as a separate latency-sensitive capability only after its runtime role and service requirements are confirmed. It may receive correlated requests, evaluate account, card, customer, balance, or credit information, publish approval or decline responses, and persist authorization state.

Azure Service Bus is the default candidate for durable commands and correlated request or response exchanges where queues, acknowledgements, retries, duplicate detection, and dead-letter handling are required. Event Hubs is more suitable for high-volume event streams and replay, but not as a direct replacement for transactional request queues. Azure Event Grid is suitable for lightweight event notification, not for workflows requiring brokered ordering and transactional handling. Existing MQ semantics, synchronization, ordering, expiry, correlation identifiers, and reply timing must be characterized before choosing or bridging these services.

The current possibility of publishing a response before later persistence requires an explicit decision. A transactional outbox can couple state persistence with eventual publication, but it changes response timing. Persisting after response can preserve observed timing but requires durable recovery and reconciliation. Neither approach can be declared equivalent without characterization.

Fraud records and rules should remain logically separate from authorization decisions unless evidence establishes a single lifecycle. Duplicate-key handling, state transitions, purge criteria, operational review, and whether fraud results block transaction acceptance are unresolved.

Reference data

Transaction types and categories should form a reference-data boundary. It should enforce confirmed dependencies, including any restriction on deleting transaction types used by categories.

A single authoritative store and versioned distribution mechanism are preferred over independently maintained DB2, VSAM, or sequential copies. Read-optimized snapshots may still be generated for coexistence or performance. Ownership, synchronization direction, refresh latency, effective dating, divergence handling, rollback, and runtime enforcement must be decided before consolidation.

Statements, reporting, and history

Statements and operational reports should be separated from online write paths where practical. Azure SQL read replicas, curated extracts, or a controlled analytical store are possible options. Azure Data Lake Storage could hold immutable or versioned extracts, reports, and migration evidence, subject to classification and retention controls. Azure Synapse Analytics or Microsoft Fabric should be considered only if reporting scale, transformation needs, governance, and support capability justify them.

Report definitions, sorting, totals, dates, formatting, distribution, legal retention, and reconciliation to transaction and balance records must be characterized. A visually similar report is not sufficient evidence of equivalence.

Batch and orchestration

Batch processing should be represented as explicit, observable workflows rather than copied job-for-job. Azure Data Factory is a candidate for data movement and scheduled transformations. Azure Functions can support bounded event-driven steps, while Azure Container Apps jobs are preferable for longer-running or runtime-specific executables. Durable Functions may coordinate stateful workflows, but their replay and determinism model must fit the processing logic. Azure Batch is an option where substantial parallel compute is demonstrated; present evidence does not establish that need.

Workflow definitions must expose prerequisites, completion signals, checkpoints, rerun rules, idempotency, destructive operations, and reconciliation. Conflicting daily, weekly, and monthly sequences must remain evidence-resolution items. No destructive delete, redefine, replace, or reload operation should be modernised until recovery and interrupted-run behaviour are tested.

Application hosting and presentation

A web presentation layer can replace CICS and BMS interaction incrementally, but screen replacement must preserve confirmed validation, messages, paging, sorting, role routing, and error distinctions unless an approved product change says otherwise.

Azure App Service is the preferred initial hosting option for conventional web applications and APIs because it provides a managed runtime, deployment slots, integration with managed identity, and reduced platform administration. Azure Container Apps is preferable where container portability, background workers, event-driven scaling, or mixed supported runtimes are required. Azure Kubernetes Service should be selected only if requirements demonstrate a need for Kubernetes-level control; it carries greater operational complexity and specialist dependency.

Azure API Management may provide authentication enforcement, throttling, versioning, and interface observability for externally or broadly consumed APIs. It need not front every internal call. Interface schemas should be versioned, but the applicable enterprise API, event, and data standards are not supplied and must be identified.

A temporary anti-corruption layer should mediate coexistence with CICS, MQ, files, DB2, IMS, or VSAM. It should translate contracts without silently normalizing conflicting lengths, keys, directions, encodings, status values, or error meanings.

Data architecture and migration

Each major dataset requires an authority decision: authoritative, derived, replicated, independently maintained, synchronized, historical, or obsolete. That decision must precede canonical modelling. A canonical model should not erase source distinctions merely to simplify implementation.

Migration pipelines should retain source values and transformation outcomes sufficiently to support reconciliation and audit, subject to data-minimization requirements. They must test fixed-width framing, encoding, blanks, zeroes, signs, delimiters, precision, overflow, truncation, invalid dates, unknown record types, duplicate and compound keys, sequence continuity, and cross-record relationships.

Every migration execution should produce controlled counts, rejected-record details, referential checks, financial or balance reconciliations where applicable, and evidence of restart safety. The unexplained IMS child-layout and unload-allocation discrepancy must be resolved before those records are transformed.

Azure Database Migration Service, Data Factory, custom containerized conversion tools, and controlled file transfer through Azure Storage are credible implementation options. Selection depends on actual source connectivity, encoding, volume, downtime, security, and repeatability. None is evidence that alternate indexes or legacy access paths have been correctly recreated.

Security architecture

Microsoft Entra ID, managed identities, and Azure role-based access control should provide platform identity and least-privilege access. Application permissions must remain explicit. Azure Key Vault should hold secrets, keys, and certificates; credentials should not be embedded in source, workflow definitions, files, or deployment parameters.

Private endpoints, segmented virtual networks, restricted outbound access, firewalls, and controlled hybrid connectivity should protect data and integration services. The required network topology and whether ExpressRoute or VPN connectivity is appropriate depend on confirmed environments, data flows, availability needs, and organizational standards.

Encryption should be applied in transit and at rest using supported Azure capabilities. Customer-managed keys should be adopted only where regulatory or organizational requirements justify their lifecycle and recovery overhead. Microsoft Defender for Cloud and relevant service-specific protection can provide posture and threat signals, while Microsoft Sentinel is a candidate for centralized security monitoring if it aligns with the organization’s security operations model.

Audit records should cover authentication, authorization decisions, privileged activity, customer and account changes, card changes, payments, transaction decisions, reference-data administration, data exports, migration actions, and operational overrides. Audit retention, immutability, access, monitoring, and legal requirements are unknown. Logging must exclude or protect passwords, card-security values, sensitive personal data, and unnecessary message payloads.

Reliability and operations

Azure Monitor, Application Insights, Log Analytics, and service-native metrics should provide correlated application, dependency, queue, database, workflow, and infrastructure telemetry. Correlation should extend across synchronous calls, asynchronous messages, migration batches, and coexistence adapters.

Operational ownership must be assigned for each component, data store, queue, batch workflow, security boundary, backup, restore, reconciliation process, and external interface. Responsibilities should include deployment, patching, certificate and secret rotation, access review, incident response, dead-letter recovery, data correction, capacity review, and supplier escalation.

Backups are not sufficient without restore testing. The design should define backup scope, point-in-time recovery, geo-recovery where justified, reconciliation after restoration, and handling of messages or external effects that fall outside database recovery. RTO and RPO remain business decisions.

Release automation should use version-controlled infrastructure and application pipelines, automated policy checks, repeatable environment creation, security scanning, database migration controls, progressive deployment, and rollback or forward-recovery procedures. The applicable Azure landing-zone, naming, tagging, policy, software-supply-chain, accessibility, records-management, and change-management standards are unknown.

Incremental delivery and coexistence

The first accepted slice should be a narrow, reversible path with observable inputs, outputs, state changes, and low coupling. A read-only account or card inquiry path may be suitable after its keys, source authority, masking, paging, and response semantics are characterized. It should establish the delivery pipeline, hybrid connectivity, identity, telemetry, reconciliation, and acceptance approach without introducing financial writes.

Subsequent candidate slices are reference-data distribution, user access migration, servicing updates, rejected-transaction recording, payment, transaction posting, reporting, authorization, fraud, and batch replacement. This is a planning order, not a committed sequence. Dependencies and risk may change it.

Each slice should include characterization tests, a preserve/change/resolve/defer decision for every relevant behaviour, contract and control, coexistence adapters, migration rehearsal, reconciliation, failure injection, rollback or forward recovery, operational runbooks, and an accepted production-readiness review. Legacy retirement should occur only after consumers, retained records, recovery needs, and parallel-run exit criteria are confirmed.

Scenarios, critical path, and capacity

A low-complexity scenario assumes that one coherent deployed baseline can be identified, relational authority can be established, interfaces can be bridged, and the first slice has limited dependencies. A central scenario assumes multiple active representations, mixed synchronous and batch integration, substantial characterization, and temporary dual operation. A high-complexity scenario assumes conflicting releases are operationally relevant, source and runtime evidence remain incomplete, compound transactions cross technologies, and migration requires prolonged reconciliation or supplier intervention.

No elapsed duration can be estimated credibly from current evidence. The critical path begins with production-baseline identification, access approval, owner assignment, interface and data-authority decisions, executable characterization, and availability of representative test data and environments. It then runs through the first end-to-end accepted slice and re-estimation.

Planning should distinguish human effort for analysis, review, test design, security decisions, and acceptance; agent or tool runtime for scans, builds, transformations, and test execution; waiting time for access, extracts, environments, suppliers, governance, and business decisions; and total elapsed calendar time. Scarce reviewers are likely to include business-rule owners, mainframe specialists, data stewards, security authorities, and operations staff, but their availability is not supplied. Shared test environments, MQ or mainframe connectivity, migration extracts, and release windows may constrain parallel work.

Business calendars, freezes, downtime tolerance, licensing, supplier obligations, data-extract windows, and test-environment capacity must be discovered. Contingency should be held for unresolved layouts, failed reconciliation, unavailable dependencies, and recovery defects. Estimates and architecture choices should be revised after the first slice is accepted.

Measures and acceptance

Benefits should not be claimed until baselines and measurement methods 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, and service latency and availability.

For every indicator, the baseline, target, accountable owner, data source, sampling period, exclusions, and review cadence are currently unknown. The first slice should establish automated collection where possible and obtain owner-approved targets before benefit reporting.

Acceptance must distinguish passed, failed, blocked by missing evidence, not executable, and not applicable. It should verify exact state changes, messages, errors, ordering, duplicate handling, concurrency, rollback, idempotency, restart, rerun, reconciliation, audit, access control, backup restoration, and external effects. Approval is required for any intentional change to confirmed behaviour.

Decisions required before implementation

The programme must identify the deployed estate and active releases; authoritative data stores and keys; transaction and commit boundaries; applicable identity and authorization model; card-data and privacy obligations; residency and retention rules; interface semantics; service levels; RTO and RPO; volume and performance profiles; batch calendar; recovery ownership; enterprise Azure standards; and accountable business, data, security, platform, and operational owners.

Until those decisions and the first characterization results exist, the Azure services described here remain options within a proposed architecture rather than approved implementation commitments.