Modernisation proposal for review; durations are indicative.

Risks and Decisions

Status and decision policy

This is an unapproved planning proposal for CardDemo modernisation on Microsoft Azure. It does not approve an architecture, migration, production release, retirement, budget, schedule, staffing model, outage allowance, service level, or benefit claim.

The available material supports only a partial source-level reconstruction. It does not prove which components are deployed, active, compatible, or production-relevant. Compilation, successful processing, catalog coverage, migration-tool completion, or similarity of screens and reports must not be accepted as evidence of semantic equivalence.

Confirmed behaviour should be preserved unless an accountable authority approves a change. Contradictory behaviour should be resolved through runtime evidence and characterization rather than silently normalized. Unsupported behaviour should be recorded as unresolved or deferred; absence from the available source is not evidence that it does not exist.

Immediate programme decisions

Establish the authoritative deployed baseline

Proposed decision: Do not begin behavioural replacement until the programme has identified the applicable releases, environments, programs, maps, copybooks, jobs, procedures, datasets, VSAM clusters and indexes, database objects, queues, load modules, configurations, scheduler definitions, generated artifacts, and external interfaces.

The inventory should distinguish runtime-confirmed behaviour, source-only evidence, optional or inactive capability, generated material, contradictions, unavailable evidence, and obsolete components. It requires access to deployed environments, catalogs, scheduler definitions, executable procedures, logs, representative data, and current operational knowledge.

Risk if unresolved: The programme could replace the wrong release, omit active consumers, preserve inactive behaviour, or retire a component that still supports an operational or recovery path.

Proposed accountable roles: A programme architecture lead should own the consolidated baseline; application and mainframe owners should validate executable components; operations should validate schedules and deployed configurations; data and interface owners should validate stores and consumers. Named people and organizational assignments remain unknown.

Require characterization before replacement

Proposed decision: Establish executable characterization and acceptance tests before replacing each path. Tests should record the environment, inputs, outputs, messages, return codes, data changes, commits, logs, external effects, timing where material, and recovery outcomes.

Acceptance should distinguish passed, failed, blocked by missing evidence, not executable, and not applicable. It should cover exact state changes, validation and error distinctions, duplicates, ordering, concurrency, rollback, idempotency, restart, rerun, reconciliation, authorization, audit, restoration, and partial failure.

Risk if unresolved: A replacement could appear functional while changing financial outcomes, rejection handling, message timing, paging, recovery, or external effects.

Proposed accountable roles: Business-rule owners should approve expected outcomes; test leadership should own the suite; application, data, security, and operations representatives should approve their respective controls. Reviewer availability is unknown.

Resolve data authority before canonical modelling

Proposed decision: Classify every significant representation as authoritative, derived, replicated, synchronized, independently maintained, historical, or obsolete before defining a canonical model or migration source.

This applies to customers, accounts, cards, cross-references, transactions, rejected transactions, balances, categories, transaction types, users, authorizations, fraud records, statements, reports, migration data, and backups. Keys, compound identities, encodings, dates, monetary precision, signs, blanks, zeroes, statuses, retention, and ownership must be resolved without erasing source distinctions.

Risk if unresolved: Migration or coexistence could introduce duplicate identities, lost relationships, balance differences, stale reference data, truncated values, or conflicting updates.

Proposed accountable roles: Domain data owners should decide authority; data stewards should approve meanings and quality rules; application owners should confirm access paths; records, privacy, and security authorities should decide retention and handling. These assignments are not yet supplied.

Use incremental and reversible delivery

Proposed decision: Deliver narrow, independently verifiable slices with coexistence, reconciliation, failure testing, rollback or forward recovery, runbooks, and production-readiness review.

A read-only account or card inquiry path is a candidate first slice only after source authority, keys, masking, paging, response semantics, connectivity, and representative data are resolved. Its purpose would be to establish identity, hybrid connectivity, delivery automation, telemetry, reconciliation, and acceptance without introducing financial writes. Conflicting card keys and paging rules may prevent it from being low risk.

Risk if unresolved: A broad replacement could combine unknown data, interface, security, and recovery problems and make rollback impractical.

Proposed accountable roles: A product or business owner should accept scope and behavioural changes; an architecture lead should approve boundaries; service operations should accept supportability; release and risk authorities should approve cutover. No approval has yet been given.

Principal risks and required decisions

Identity, authorization, and user administration

Sign-on appears to validate security data and route administrative and ordinary users, but this does not establish a complete authorization model. Password representation, retry and lockout behaviour, session handling, identity propagation, user-type enforcement, RACF relationships, deletion policy, audit, and effective permissions remain unknown.

Proposed direction: Use Microsoft Entra ID for workforce authentication where the population and organizational model permit it, managed identities for workloads, and explicit application authorization for business permissions. Azure role assignments alone should not substitute for application authorization.

Legacy passwords should not be copied unless their protection and migration method are demonstrably safe and supported. Controlled reset or staged federation are alternatives requiring business and security approval.

Decision required: Determine the authority of legacy security records, the target identity population, role model, segregation of duties, lockout and session standards, privileged and break-glass access, deletion policy, and audit requirements.

Risk: Incorrect migration could weaken access controls, prevent legitimate access, retain unsafe credentials, or conflate routing attributes with authorization.

Account, customer, and card consistency

Account maintenance appears to compare submitted values with previously retrieved values and to use locking or concurrent-update detection. A customer-update failure after an account update is intended to cause rollback. Card maintenance has observed validation rules, but card identity, uniqueness, key composition, update scope, page sizes, and attention-key behaviour conflict.

Proposed direction: Preserve confirmed validation, not-found distinctions, concurrency protection, and intended rollback. Azure SQL Database is the leading candidate where relational constraints and local transactions fit the recovered semantics. Azure SQL Managed Instance remains an option if compatibility or instance-level capabilities are required. Azure Cosmos DB should be deferred where partition boundaries complicate compound consistency. PostgreSQL on Azure remains possible but is not justified by present evidence.

Decision required: Resolve lock scope, deadlock and retry behaviour, account and customer atomicity, card compound keys, identity mutability, uniqueness, paging, and treatment of CVV-like values.

Risk: Lost updates, partial customer and account changes, incorrect card selection, identity collisions, or prohibited retention of card-security data.

Payments and financial posting

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 a balance. Identifier generation, duplicate semantics, exact balance effects, concurrency, commit boundaries, and recovery remain unresolved.

Proposed direction: Where transaction creation and balance adjustment share a database, use a local transaction. If separated later, use durable commands, idempotency keys, explicit states, an outbox, compensation, and reconciliation rather than assuming distributed transactions.

Decision required: Establish authoritative balances, identifier rules, atomicity, rollback, duplicate treatment, restart behaviour, and reconciliation tolerances before any financial write is cut over.

Risk: Duplicate payment, missing transaction records, incorrect balances, partial writes, or unsafe replay.

Accepted and rejected transactions

Accepted and rejected transactions must remain distinguishable, and rejected work should retain reasons and not count as successful processing. The complete processing chain is unknown because similarly named components provide conflicting evidence about substantive writes. Calculations and lifecycle rules for interest, fees, discounts, category balances, reversals, refunds, and status transitions are incomplete.

Proposed direction: Model explicit outcomes only after they are evidenced. Preserve rejection reasons and separate reconciliation of accepted and rejected work.

Decision required: Resolve authoritative posting components, exact calculations, states, retention, privacy, replay eligibility, rerun treatment, and commit boundaries.

Risk: Rejected work could be posted or counted, accepted work could be omitted, or reruns could create duplicates.

Authorization messaging and persistence

Authorization may consume correlated MQ requests, issue approval or decline responses, and persist summary and detail information. Evidence indicates that responses may be published before later persistence and that MQ work may lack synchronization.

Proposed direction: Azure Service Bus is the leading candidate for durable commands and correlated exchanges requiring acknowledgements, retries, duplicate detection, and dead-letter handling. Event Hubs should be considered only for demonstrated stream and replay requirements; Event Grid should be limited to lightweight notifications.

A transactional outbox would couple persistence and publication but might change response timing. Preserving response-before-persistence would require durable recovery and reconciliation.

Decision required: Resolve correlation, ordering, expiry, acknowledgement, synchronization, reply timing, duplicate handling, persistence authority, and failure semantics before selecting or bridging messaging services.

Risk: External approval or decline could be issued without durable state, retried requests could receive inconsistent outcomes, or target messaging could alter observable timing.

Fraud processing

Fraud criteria, lifecycle, purge rules, operational review, duplicate handling, and relationship to transaction acceptance are not established.

Proposed decision: Keep fraud logically separate from authorization until evidence proves a shared lifecycle. Do not select a target rules or decision platform from current evidence.

Risk: Premature consolidation could alter blocking behaviour, erase review states, or apply incorrect retention and purge rules.

Reference data

Transaction types and categories may be administered in DB2 while processing consumes VSAM or sequential copies. Referential restrictions may prevent deletion of transaction types used by categories.

Proposed direction: Prefer one authoritative store with versioned distribution and controlled snapshots for coexistence, while preserving confirmed dependency rules.

Decision required: Confirm whether the capability is active and decide ownership, synchronization direction, refresh latency, effective dating, divergence handling, rollback, rerun behaviour, and runtime enforcement.

Risk: Consumers could process against stale or conflicting categories and transaction types.

Batch and destructive file operations

Daily, weekly, and monthly sequences conflict over posting, backups, waits, file state, interest, deletion, indexing, reporting, and recovery. Some destructive paths show deletion without demonstrated recreation or reload.

Proposed decision: Reconstruct workflows from confirmed prerequisites, completion signals, checkpoints, rerun rules, and business outcomes rather than copying job names. Do not replace delete, redefine, replace, unload, reload, or index-rebuild operations until interrupted-run and recovery behaviour is tested.

Azure Data Factory, Azure Functions, Azure Container Apps jobs, and Durable Functions are options whose suitability depends on the recovered workflow. Azure Batch should remain deferred unless parallel-compute demand is demonstrated.

Risk: Incorrect ordering, data loss, stale indexes, duplicate processing, unrecoverable partial runs, or reports based on incomplete data.

Migration and reconciliation

Migration flows appear to split multi-record exports, but framing, mappings, encoding, sequence handling, counts, checksums, unknown records, relationships, and index recreation are incomplete. The IMS child-layout and unload-allocation discrepancy remains unresolved.

Proposed decision: Require repeatable rehearsals with controlled counts, rejected-record details, referential checks, applicable financial reconciliation, and restart evidence. Tool choice among Azure Database Migration Service, Data Factory, Azure Storage transfer, and custom conversion should follow connectivity, encoding, volume, downtime, security, and repeatability evidence.

Risk: A technically successful load could still omit records, misframe data, corrupt values, lose access paths, or fail reconciliation.

Security and sensitive information

The estate references credentials, passwords, customer information, card data, CVV-like values, datasets, queues, FTP, and administrative paths. Effective permissions, encryption, transport protection, segmentation, audit, and regulatory scope are not established.

Proposed direction: Use least privilege, managed identities, Azure Key Vault, encryption, private connectivity where justified, restricted outbound access, protected logging, and explicit application authorization. Logs should exclude passwords, card-security values, unnecessary personal data, and unnecessary payloads.

Decision required: Confirm card-data and privacy obligations, residency, retention, key-management requirements, network topology, hybrid connectivity, audit controls, and security-operations integration.

Risk: Sensitive data could be retained, transmitted, logged, or accessed contrary to obligations. Sensitive-looking fields alone do not prove populated content or exposure.

Backup, restore, and external effects

Backup generations are described, but retention, restore capability, reconciliation, and handling of messages or other external effects are unknown.

Proposed decision: Treat tested restoration and reconciliation, rather than backup creation, as the recovery control. Define database recovery together with queue, file, report, and externally published effects.

Decision required: Set backup scope, retention, restore testing, point-in-time and geo-recovery needs, recovery ownership, RTO, and RPO.

Risk: A database might be restored while messages, balances, indexes, or downstream effects remain inconsistent.

Operational and architectural assumptions requiring validation

The proposal assumes only that Azure is the target platform and that managed services are preferable when they meet confirmed semantics and support needs. It does not assume that every legacy program becomes a service, that every domain needs independent deployment, or that DB2, IMS, MQ, VSAM, and batch components all operate together.

Availability, latency, throughput, peak volume, retention, residency, maintenance windows, outage tolerance, RTO, and RPO are unknown. Application hosting remains conditional: Azure App Service is the preferred initial option for conventional web applications and APIs; Azure Container Apps is an alternative for containerized workers or mixed runtimes; Azure Kubernetes Service should be selected only if Kubernetes-level control is demonstrated as necessary.

Enterprise landing-zone, naming, tagging, API, accessibility, records-management, change-management, software-supply-chain, and security standards have not been supplied and must be discovered before implementation.

Delivery scenarios, critical path, and capacity

A low-complexity scenario assumes one coherent deployed baseline, clear relational authority, bridgeable interfaces, and a first slice with 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 remain relevant, runtime evidence is incomplete, transactions cross technologies, and reconciliation or supplier intervention is prolonged.

No elapsed duration is supportable. The critical path begins with environment access, baseline identification, accountable owner assignment, data-authority and interface decisions, representative test data, and executable characterization. It continues through an accepted end-to-end first slice and subsequent re-estimation.

Planning should distinguish human analysis and review, agent or tool runtime, waiting time for access and decisions, and 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 unknown. Shared environments, connectivity, extract windows, release windows, licensing, supplier obligations, business calendars, and change freezes remain dependencies to discover.

Contingency should be retained for unresolved layouts, failed reconciliation, unavailable interfaces, conflicting releases, and recovery defects. No budget, staffing, date, price, or outage commitment should be inferred.

Benefits and measurement decisions

No reliability, security, cost, speed, or supportability benefit should be claimed until a baseline and measurement method 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 selected indicator, the baseline, target, accountable owner, data source, sampling period, exclusions, and review cadence must be approved. The first accepted slice should establish automated collection where practical. Historical counts or lateness observations should not be used as baselines without validating their period, workload, collection method, and present relevance.

Approval gates

Implementation should not proceed beyond discovery until the deployed baseline, owners, access, and evidence register are accepted. A slice should not enter build until its business rules, data authority, interfaces, security obligations, acceptance tests, and recovery approach are defined. It should not enter production until migration and coexistence have been rehearsed, reconciliation and failure testing pass, operational ownership and runbooks are accepted, and rollback or forward recovery is viable.

Legacy retirement should remain prohibited until all consumers, retained records, recovery dependencies, parallel-run exit criteria, and external obligations are confirmed. Any intentional change to confirmed behaviour requires explicit approval from the accountable business and control authorities.