Modernisation proposal for review; durations are indicative.

Target Architecture

Proposal status and evidence boundary

This is an unapproved target-architecture proposal for modernisation on Microsoft Azure. It does not approve a platform choice, domain redesign, migration, budget, staffing model, outage, service level, data residency position or change to existing business behaviour.

The supplied Modernisation Planning Summary establishes broad capabilities and risks but not the complete executable system, production topology, schema, traffic profile, integration estate or operational model. Architecture decisions therefore require discovery and characterization before commitment. Existing interfaces, state meanings, validation outcomes, error responses, ordering, persistence timing, audit intent, event timing, documents and reports remain compatibility constraints until their consumers and contractual significance are confirmed.

The target should improve change safety, security, supportability, recoverability and operational visibility without treating processing coverage or successful compilation as proof of semantic equivalence.

Architectural direction

Adopt an incremental modular architecture with explicit domain boundaries, server-side policy enforcement and well-defined transactional seams. Begin with a modular deployable rather than assuming that every domain requires an independently deployed microservice. Extract a domain into a separate service only where evidence demonstrates a distinct scaling profile, security boundary, release cadence, availability need, integration role or operational owner.

Use managed Azure services where they satisfy confirmed runtime, residency, support, latency and regulatory requirements. Retain coexistence adapters around legacy routes, database structures, files, reports and external integrations during migration. No component should be replaced until its current contract has characterization tests, a migration and reconciliation method, and an accepted rollback or forward-recovery plan.

The architecture should separate:

• request handling and compatibility translation;
• identity, authentication and authorization policy enforcement;
• domain commands, queries and lifecycle rules;
• transactional persistence and concurrency control;
• documents, files and malware-scanning workflow;
• durable integration and event delivery;
• reporting and analytical projections;
• audit, telemetry and operational controls.

This separation must not alter import, export and transit asymmetry or collapse notifications, assessments, movements, shipments, receipts, guarantees and status history into generic records without an approved business decision.

Proposed domain boundaries

Notification and assessment

This boundary should own notification identity, type-specific import, export and transit behaviour, submission, assessment, consent, objection, withdrawal, prohibition, closure, unlocking and resubmission rules. It should not infer lifecycle progression from enum order.

The submitted-versus-awaiting-payment contradiction must be resolved before defining the state machine or migration mapping. The transition graph should identify actor, preconditions, editability, authorization, event, audit outcome and failure semantics for every accepted transition.

Notification-number normalization and authority-specific allocation belong here, subject to confirmed uniqueness scope, format and concurrency rules.

Movement and shipment

This boundary should own movement identifiers, shipment numbers, commencement, submission, receipt, partial rejection, rejection, recovery, completion and cancellation. External and internal receipt and completion paths should remain distinct until equivalence is demonstrated.

Receipt and rejection precedence, partial-rejection completion, quantity effects, cancellation versus deletion, identifier allocation and bulk-operation atomicity remain design decisions. Allocation based on the smallest unused positive number requires database-level concurrency protection if it is retained.

Parties, organisations and locations

This boundary should represent organisations, users, memberships, owners, producers, exporters, importers, carriers, facilities, treatment sites, authorities and customs offices. It should be the authoritative source for relationship and cardinality checks used by other domains.

Posted or hidden relationship identifiers must never establish ownership or authorization. Current records must be reloaded and checked against the authenticated subject, organisation, authority, role and applicable lifecycle state.

Routes and classification

This boundary should own ordered transit states, countries, entry and exit points, authorities, customs offices, transport methods, waste classifications, operations, packaging and applicable reference data.

Historical meanings of obsolete codes, sentinel values, “not listed” and “not applicable” must be preserved. Route multiplicity, transit resequencing, customs requirements, facility cardinality and classification completeness require explicit contracts rather than normalization by a generic model.

Finance and pricing

This boundary should own payments, refunds, balances, pricing selection and effective-dated authority-specific rules. Currency, precision, tax, rounding ownership, overlapping-price precedence, missing-price behaviour and treatment of records containing both credit and debit remain unresolved.

Financial calculations should use explicitly selected decimal precision and rounding rules. They must not be reconstructed from display values. Changes to pricing require effective dating, auditability and deterministic replay against the rule version applicable to the business event.

Guarantees

This boundary should own guarantee application, completion, approval, refusal, release and supersession. It should enforce confirmed eligibility, reference, cover, date and active-load rules.

The permitted number of approved guarantees, matching-reference behaviour, self-approval, release versus supersession and event timing must be decided before target constraints are introduced.

Documents, files and correspondence

This boundary should own document templates, rendered outputs, annexes, uploads, downloads, comments and correspondence metadata. Existing filenames, formats, visible content, ordering and layouts remain compatibility-sensitive.

Binary content should be separated from transactional metadata, but authorization must be evaluated using authoritative business records on every upload and download. Generated document identity and template version should be recorded so an output can be explained or reproduced where the governing retention policy requires it.

Reporting and audit

Operational reporting should be separated from command processing through controlled read models or replicas where freshness requirements permit. Existing report columns, aliases, workbook structure, status derivation, date boundaries, ordering and null handling must be characterized before replacement.

Security audit, business history and diagnostic telemetry are distinct. An append-oriented business audit record should capture actor, action, target, time, result and correlation context without exposing unnecessary sensitive data. Attempted, denied, failed and successful operations must not be conflated.

Azure platform options

Application hosting

Azure App Service is the preferred initial candidate for an HTTP application when the recovered runtime is supported and there is no confirmed requirement for complex container orchestration. It offers managed patching, deployment slots, autoscaling and relatively low operational overhead.

Azure Container Apps is a credible alternative where container packaging, event-driven workers, independent scaling or revision-based deployment are advantageous. It adds container and networking complexity but avoids managing a Kubernetes control plane.

Azure Kubernetes Service should be selected only if confirmed requirements justify its operational cost, such as specialised networking, extensive workload orchestration or platform capabilities unavailable from simpler services. The evidence does not currently justify it.

Azure Functions may suit bounded asynchronous tasks, schedules and integration handlers. It should not become the default home for long-running business workflows without confirming duration, retry, idempotency, networking and hosting-plan behaviour.

The final selection depends on the application runtime, operating-system dependencies, document-conversion software, background processes, scaling characteristics and supplier support.

Transactional data

Azure SQL Database is the leading candidate if the recovered data model and SQL behaviour are compatible. It provides managed backups, encryption, high-availability options and established relational transaction support.

Azure SQL Managed Instance may be more suitable during coexistence if the application materially depends on instance-scoped features, cross-database operations, SQL Agent or incompatible stored procedures. It has greater cost and networking complexity. These dependencies must be inventoried rather than assumed.

A database-per-service split is not initially proposed. A shared Azure SQL deployment with schema ownership and prohibited cross-boundary writes can support gradual modularisation. Physical separation may follow where security, scale or independent lifecycle requirements justify it.

Cosmos DB should not replace relational records merely for modernisation. It would require evidence that its consistency, partitioning and query model suit the transactional contracts.

Files and documents

Azure Blob Storage is the preferred candidate for uploaded and generated binary content, using private containers, encryption, immutable or versioned retention where required, and short-lived access mediated by the application. Blob metadata must not replace authoritative relational ownership and authorization data.

Uploads should enter a quarantine state. A durable scanning workflow should validate size, permitted content and signatures, invoke an approved malware-scanning capability, and promote only clean files. Unknown, timeout and error outcomes should fail safely according to an agreed business contract. Scanner product, retention, rescan policy and operational owner remain undecided.

Messaging and integration

Azure Service Bus is the preferred candidate for durable commands and integration events requiring queues, topics, duplicate handling, dead-lettering and controlled retries. Azure Event Grid may suit lightweight notifications where durable ordered business processing is not required. Neither should substitute for a database transaction.

A transactional outbox should record integration intent alongside the business change. A publisher should deliver messages with stable business identifiers and idempotency information. Consumers must tolerate duplicates. Ordering scope, retry limits, replay authority, dead-letter ownership and reconciliation schedules require definition.

Existing synchronous interfaces should remain synchronous where callers depend on immediate results. Adapters should isolate external company and identity lookups, payments, email, scanning, document conversion and reporting clients behind explicit authentication, timeout, cancellation, retry and failure-mapping contracts.

Identity and secrets

Microsoft Entra ID is the candidate workforce and service identity provider. External customer identity requires a separate decision based on the confirmed user population and current account lifecycle. Migration must preserve required user-to-business relationships and must directly verify any auto-confirmation, password-reset and email-verification behaviour.

Azure Managed Identities should be used for service-to-service access where supported. Azure Key Vault should hold secrets, keys and certificates, with access granted through least-privilege identities and audited rotation procedures. Bearer and cookie authentication, identity precedence, claims transformation, token storage and inactive-user handling require an explicit target contract.

Observability and security operations

Azure Monitor, Application Insights and Log Analytics are candidates for metrics, distributed traces, structured logs, dependency telemetry and alerts. Correlation should span HTTP requests, business commands, database commits, outbox publication, message handling and external calls.

Microsoft Defender for Cloud and the relevant workload protection capabilities should be evaluated against the approved threat model and licensing. Azure Front Door with Web Application Firewall or Application Gateway with Web Application Firewall may protect public entry points; the choice depends on global routing, private networking, TLS termination and residency requirements. These controls supplement rather than replace application authorization and input validation.

Interface and compatibility principles

Existing route shapes, status codes, messages, nullability, ordering and document or report formats should be preserved through compatibility endpoints or translation layers until callers are inventoried and changes are accepted. State-changing GET operations should be characterized and then replaced by explicit protected commands, with a managed consumer transition.

Commands should include an authenticated actor context, authoritative resource identifier and concurrency token where stale updates are possible. Every mutation must reload current state, verify ownership and relationships, enforce transition policy and validate cross-field values. Idempotency keys or equivalent deduplication should be considered for retry-prone creation, payment, movement and bulk operations, but their scope and retention must be agreed.

Dates should be represented according to their meaning: date-only values for business dates and timezone-aware instants for processing events. A clock abstraction and named business-calendar service should apply agreed authority-specific working-day rules. No calendar, timezone or boundary convention is selected by this proposal.

Data integrity and migration

Migration should use profiled source data, deterministic transformations and retained rejection records. Preflight checks must cover nulls, duplicates, orphans, invalid references, guarantee cardinality, status combinations, units, precision, collation and applied migration state.

Each slice should define source-to-target counts, business-key reconciliation, referential checks, financial and quantity totals where semantically valid, sampled document comparison, report comparison and lifecycle invariants. Reconciliation differences must be classified rather than silently corrected.

Coexistence may require change capture, dual reading or controlled replication. Uncontrolled dual writing should be avoided because partial failure obscures the authoritative record. Where temporary dual writing is unavoidable, one system must remain authoritative and a durable reconciliation process must exist.

Destructive changes should follow accepted backup, restore, checkpoint, rerun and remediation procedures. Rollback feasibility depends on whether target writes can be represented safely in the legacy model; otherwise forward recovery is required.

Security model

Authorization should be expressed as centrally testable policies evaluated against action, authenticated identity, organisation, authority, ownership, membership, resource and lifecycle state. Presentation controls, hidden fields and route declarations are not authorization controls.

Administrative privileges should be scoped and separated from ordinary business roles. High-impact actions such as reassignment, ownership transfer, deletion, guarantee decisions, finance changes, archive operations and user administration should receive explicit policy and audit review. Whether dual control is required is a business and regulatory decision.

Data should be encrypted in transit and at rest using Azure-supported mechanisms. Network exposure, private endpoints, firewall rules and egress restrictions should follow a documented threat model. Retention, legal hold, audit immutability, data classification, residency and deletion requirements remain unknown and must be decided before production design.

Reliability and operational responsibility

Availability, recovery-time objective, recovery-point objective, performance, retention and support hours are unresolved service decisions. They must be set per critical user journey and dependency before selecting service tiers.

The product owner should own business behaviour, lifecycle decisions and acceptance. Security owners should own identity policy, threat modelling, incident requirements and exceptions. Data owners should approve meanings, retention and migration reconciliation. The platform team should own Azure foundations, networking, identity integration, deployment tooling, patching and shared observability. Application teams should own code, domain telemetry, runbooks and dependency behaviour. Operations should own alert response, recovery exercises and incident coordination. Supplier responsibilities for scanning, payments, conversion, email and identity must be contractually identified.

Backups are insufficient without scheduled restore tests. Runbooks should cover failed deployment, unavailable dependency, stuck queue, dead-letter replay, scanner outage, orphaned file, event publication failure, report divergence, credential rotation and migration interruption.

Delivery sequence

The first slice should recover the executable baseline and establish inventory, build, deployment, telemetry and a representative end-to-end characterization path without changing business behaviour.

Subsequent slices should resolve lifecycle and security contracts, introduce server-side authorization policies, establish durable integration and file controls, and replace bounded capabilities behind compatibility interfaces. Data migration should follow profiling and accepted reconciliation rules. Reporting and document replacement should occur only after output comparison is automated.

Every release should be independently verifiable, support coexistence, and define rollback or forward recovery. Feature flags may separate deployment from activation, but flags affecting authorization or data meaning require controlled configuration, audit and removal plans.

Low, central and high delivery scenarios cannot yet be estimated responsibly. They 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 critical path currently runs through executable-baseline recovery, contract resolution, identity and authorization discovery, data profiling, and access to external dependencies. Business calendars, freezes, downtime allowances, licences, test environments, production-like data access and supplier lead times remain planning dependencies.

Measures and decision gates

Benefits should not be claimed until baselines exist. Candidate indicators include deployment frequency, change lead time, failed-change rate, restoration time, availability, unresolved security findings, unsupported dependencies, backup-restore success, dead-letter age, reconciliation differences, authorization-test coverage and production incident rate.

For each indicator, the baseline, target, accountable owner, data source, sampling period and calculation method must be approved. Initial work should instrument these measures and collect a representative baseline rather than invent targets.

Architecture approval should require confirmed runtime and topology, agreed domain contracts, an action-resource authorization matrix, data profiles, interface inventory, service-level decisions, threat model, residency and retention decisions, Azure option validation, an operational ownership model, cost assessment, and demonstrated migration and recovery procedures. Until those gates are met, this architecture remains a planning hypothesis rather than a production commitment.