Modernisation proposal for review; durations are indicative.

Risks and Decisions

Status and evidence boundary

This document is an unapproved planning proposal for incremental modernisation on Microsoft Azure. It records evidence-backed risks, unresolved contradictions, proposed options, accountable roles and decision gates. It does not approve an architecture, migration, business-rule change, budget, staffing model, delivery date, outage, service level, data-residency position or production cutover.

The available material does not establish the complete executable application, deployed schema, active interfaces, middleware, callers, integrations, runtime configuration, production behaviour, operational ownership or authorization enforcement. Missing, malformed and contradictory evidence must be recovered or resolved. Compilation, processing coverage and successful tests do not establish semantic equivalence or production readiness.

Existing business behaviour remains a compatibility constraint until characterized and explicitly accepted for preservation or change. This includes interfaces, status meanings, validation and error responses, nullability, ordering, persistence and event timing, audit intent, identifiers, calculations, documents, reports and navigation.

Proposed decision authority

The following accountabilities are proposed and require organizational confirmation:

• The product owner should approve lifecycle behaviour, user-visible compatibility, prioritization and business acceptance.
• Named business and policy owners should decide notification, movement, route, classification, calendar and guarantee rules.
• The finance owner should decide pricing, payments, refunds, currency, precision, tax and rounding contracts.
• The security owner should approve the threat model, identity and authorization policies, high-impact access, incident requirements and exceptions.
• The data owner should approve data meanings, retention, migration transformations, reconciliation tolerances and treatment of rejected or historical records.
• The architecture authority should approve Azure service choices and departures from the incremental modular direction.
• The platform owner should own Azure foundations, networking, deployment automation, managed identity, secrets integration and shared observability.
• Application owners should own domain implementation, compatibility tests, dependency behaviour, telemetry and runbooks.
• Operations should own monitoring response, recovery exercises, incident coordination and operational readiness.
• Supplier owners should be identified for identity, payments, email, scanning, document conversion and other external dependencies.

No decision should be treated as approved merely because a proposed role is named here.

Immediate evidence and security risks

Incomplete executable and operational baseline

The largest planning risk is that architecture and migration choices may be based on an incomplete account of the system. Unsupported runtime dependencies, active routes, stored procedures, scheduled work, production-only configuration or unknown callers could invalidate design and estimates.

The proposed response is to make baseline recovery the first release slice. It should produce a reproducible build and deployment, an inventory of runtime and database components, and a traced end-to-end business path covering authorization, validation, persistence, audit, events, files and external effects.

The proposed accountable roles are the application owner and platform owner, with database, security and operations participation. Acceptance should require demonstrated execution in a representative environment rather than compilation alone.

Unproven authorization enforcement

Authorization may be distributed across routes, controllers, filters, middleware, handlers, repositories, services and database procedures. User-interface controls, hidden fields and authorization declarations do not prove enforcement. Anonymous or scanner-like endpoints, state-changing retrieval methods, broad administration, identity coercion and possible default-allow behaviour require priority investigation.

The proposed response is to inventory actions and resources, trace identity and ownership checks end to end, and create an action-resource-state authorization matrix. Every mutation should reload authoritative records and verify identity, organisation, authority, ownership, membership, relationships and lifecycle state.

The security owner should be accountable for policy approval; application owners should be accountable for implementation evidence. High-impact actions require explicit review, including ownership transfer, reassignment, deletion, archive, guarantee decisions, finance changes, sharing and user administration.

Identity and temporary-state exposure

Bearer and cookie precedence, token refresh, claims transformation, inactive-user behaviour, client credentials, password reset and email verification are unresolved. Any environment-wide auto-confirmation or attacker-influenced polymorphic temporary-state deserialization could create material exposure.

Direct runtime verification is required before identity migration. The security owner should decide acceptable identity flows and failure responses. The external customer identity platform remains deferred until the user population, account lifecycle and required business relationships are confirmed.

File and document handling

Upload and download controls are incomplete. Risks include unauthorized access, unsafe content, scanner outage, ambiguous scan results, temporary-file leakage, unsafe names and paths, orphaned files and retention failures.

The proposed target is private Azure Blob Storage with relational metadata remaining authoritative. Uploads should be quarantined until size, permitted content, signature and malware checks complete. Unknown, timeout and error outcomes require an explicit business decision; they must not be assumed equivalent to clean.

The security, data and operations owners should jointly approve scanner behaviour, retention, cleanup, legal hold, rescan policy and incident handling. Existing document names, layouts, formats, ordering and visible content remain preserved pending automated comparison and consumer acceptance.

Business-contract decisions

Notification submission and payment state

There is a material contradiction over whether submission persists a submitted state, moves directly to awaiting payment, or treats awaiting payment as subordinate information. This affects authorization, display, reporting, payment and movement eligibility.

Options are to retain distinct persisted states, make awaiting payment subordinate to a submitted state, or define a direct transition that does not retain submitted as a stable state. No option is preferred without runtime and business evidence.

The product, policy, finance and reporting owners should jointly decide. Acceptance must define the transition sequence, actor, persistence point, editability, payment eligibility, audit entry, event timing, report mapping and migration of existing combinations.

Lifecycle transition graphs

Observed notification and movement states do not establish complete transition graphs. Withdrawal, resubmission, unlocking, prohibition, closure, archive, cancellation, deletion and terminal-state behaviour remain uncertain. Enum order must not be used as lifecycle order.

The decision should be an explicit transition contract for each import, export and transit workflow and for each movement path. It must define preconditions, actor, authorization, editability, persistence, audit, events and failure semantics. Import, export and transit asymmetry must be preserved unless a specific convergence is approved.

Receipt, rejection and completion precedence

Receipt, partial rejection, rejection, recovery and completion may create competing records or overwrite information. It is unknown whether a partially rejected movement may complete, whether partial rejection can equal the actual quantity, or which outcome controls display and reporting.

The movement business owner should decide an authoritative outcome model. Acceptance must cover internal and external paths, duplicate and stale requests, whitespace-only reasons, quantity effects, multiple outcome records, future and backdated dates, and bulk-operation failure. Existing internal and external differences should remain until equivalence is demonstrated.

Identifier allocation and lookup

Notification-number normalization and authority scope, movement-number allocation, shipment-number bounds and malformed or unmatched lookup responses are unresolved. Retaining smallest-unused-positive allocation without locking could create duplicates under concurrency.

Visible formats and confirmed lookup behaviour should be preserved. If the allocation rule remains, it should gain database-level concurrency protection and uniqueness enforcement at the approved scope. The product and data owners should approve formats and scope; application and database owners should prove concurrent behaviour.

Dates and business calendars

Evidence contains conflicting calendar-day, working-day, consent-period and movement-window limits. Inclusivity, holiday sources, timezones, start-date treatment, precedence and warning-versus-blocking behaviour are not established.

Rules should be resolved workflow by workflow rather than normalized. The target should distinguish date-only business values from timezone-aware processing instants and use a named calendar service and controllable clock. Policy owners must approve each rule and calendar source. Boundary tests should cover malformed values, daylight and timezone effects where relevant, report ranges, receipt and recovery ordering, and payment and refund dates.

Quantities, units and rounding

Tonnes, kilograms, litres and cubic metres are present, with inconsistent handling of zero, negative, null and incomplete values. Conversion factors, mixed-unit compatibility, decimal precision, tolerance, overflow and rounding ownership are unknown.

Historical values and visible outcomes should be preserved until contracts are approved. Heuristic conversion must not be accepted as authoritative. Business and data owners should approve unit compatibility and precision; acceptance should reconcile semantically valid totals and test operation ordering and boundary values.

Finance and pricing

Currency, tax, precision, effective-date selection, overlapping-price precedence, missing prices, credits, debits, balances, refunds and records containing both credit and debit remain unresolved. Conflicting calculator evidence prevents a claim of equivalence.

The finance owner should approve deterministic calculation and replay rules. Existing records and outputs should remain preserved while the rules are established. Acceptance must include zero and negative amounts, future and pre-payment refund dates, rounding, overlapping price rows, missing prices and downstream invoice or report consumers.

Guarantee cardinality and decisions

Evidence conflicts over whether one or multiple approved guarantees are permitted. Approval, refusal, release, supersession, matching references, self-approval and active-load eligibility are also unresolved.

No new uniqueness constraint should be introduced until source data is profiled and the business rule is approved. The guarantee business owner and security owner should decide cardinality and separation-of-duty requirements. Acceptance must include concurrent approvals, failed decisions, decision history, transaction boundaries and event behaviour.

Routes, facilities and reference data

Route multiplicity, transit resequencing, customs requirements, European-route behaviour, facility cardinality and treatment-site cardinality conflict. Waste and operation codes include historical, obsolete and sentinel meanings that must not be silently normalized.

The data and business owners should approve canonical meanings and cardinalities. Historical “not listed,” “not applicable” and obsolete values should remain distinguishable. Migration acceptance must detect duplicates, missing ordinals and invalid relationships without silently deleting or reclassifying records.

Architecture and platform decisions

Deployment model

The proposed initial direction is a modular deployable with explicit domain boundaries and compatibility adapters. The evidence does not justify a service-per-domain architecture.

Azure App Service is the leading hosting candidate if runtime and operating-system dependencies are supported. Azure Container Apps is an alternative for container-dependent workloads or independently scaled workers. Azure Functions may suit bounded asynchronous tasks. Azure Kubernetes Service should remain deferred unless confirmed orchestration or networking requirements justify its operational burden.

The architecture authority should decide only after runtime, document conversion, background processing, scaling, networking and supplier support are confirmed.

Transactional data platform

Azure SQL Database is the leading candidate if existing SQL behaviour is compatible. Azure SQL Managed Instance is a coexistence option where instance features, cross-database operations, SQL Agent or incompatible procedures are material. Cosmos DB is not proposed as a default replacement for relational records.

A shared deployment with controlled schema ownership is preferred initially over database-per-service. Cross-boundary writes should be prohibited through design and review. Physical separation should follow only where security, scaling, availability or ownership evidence justifies it.

Durable integration

Database changes, events, files, audits, caches and external effects may currently commit independently. Azure Service Bus with a transactional outbox is the preferred candidate for durable business integration. Event Grid may be considered for lightweight notifications that do not require durable ordered processing.

Existing synchronous interfaces must remain synchronous where callers depend on immediate results. Before adoption, owners must decide ordering scope, idempotency, retry limits, replay authority, dead-letter ownership and reconciliation. Messaging must not be represented as part of a database transaction unless the transactional boundary is demonstrated.

Observability and operations

Azure Monitor, Application Insights and Log Analytics are candidates for correlated telemetry. Correlation should span requests, commands, database commits, outbox publication, message handling and external calls.

Availability, recovery-time, recovery-point, performance, retention and support-hour targets are unknown. Service tiers must not be selected from invented targets. Operations and product owners should establish critical journeys and service decisions before production approval. Backup arrangements require scheduled restore tests.

Data migration risks and controls

Historical migrations indicate risks of destructive deletion, truncation, precision or timezone loss, nondeterministic survivor selection, row multiplication, orphaning, ambiguous status backfills and loss of historical reference meaning.

No destructive migration should proceed before profiling nulls, duplicates, orphans, invalid references, status combinations, approved-guarantee cardinality, units, precision, collation and applied migration state. Transformations must be deterministic, retain rejected records and define survivor rules.

Each migration slice should have source-to-target counts, business-key reconciliation, referential checks, semantically valid financial and quantity totals, document or report comparison where applicable, checkpoints, rerun behaviour and rollback or forward recovery. Differences should be classified and approved rather than silently corrected. Uncontrolled dual writing should be avoided; if unavoidable, one system must remain authoritative and durable reconciliation is required.

Delivery, measurement and approval gates

Delivery should use independently verifiable coexistence slices. The first slice should recover the baseline, establish deployment and telemetry, and characterize one representative path without changing business behaviour. Subsequent slices should resolve lifecycle and authorization contracts, strengthen server-side enforcement, introduce file and integration controls, and replace bounded capabilities behind compatibility interfaces.

Low, central and high delivery scenarios cannot yet be responsibly quantified. Budget, staffing, dates, prices and outage allowances remain unknown. Scenarios should be produced after the first accepted slice using measured human effort, automated-agent runtime, supplier waiting time and elapsed calendar time. Capacity assumptions must identify scarce business decision-makers, security reviewers, database specialists and shared integration environments.

The current critical path runs through executable-baseline recovery, business-contract resolution, identity and authorization discovery, data profiling and access to external dependencies. Change freezes, business calendars, downtime allowances, environment access, production-like data, licences and supplier lead times remain explicit dependencies.

Benefits must not be claimed before baselines exist. Candidate measures include deployment frequency, change lead time, failed-change rate, restoration time, availability, unresolved security findings, unsupported dependencies, restore-test success, dead-letter age, reconciliation differences, authorization-test coverage and production incident rate. Each measure requires an approved baseline, target, accountable owner, data source, sampling period and calculation method.

Architecture approval should require confirmed runtime and topology, approved domain and authorization contracts, data profiles, interface and consumer inventories, service-level decisions, threat model, residency and retention decisions, validated Azure options, operational ownership, cost assessment, and demonstrated migration, reconciliation and recovery procedures. Production cutover should additionally require compatibility acceptance, security approval, operational runbooks, restore evidence, controlled activation and an accepted rollback or forward-recovery plan.