Modernisation plan

Modernisation Plan

Proposal status and evidence boundary

This is an unapproved planning proposal for incremental modernisation on Microsoft Azure. It does not approve an architecture, migration, budget, staffing model, delivery date, outage, service level, data-residency position, business-rule change or production cutover.

The supplied material describes selected application, database, integration, document, report, test and migration artefacts, but does not establish the complete executable system or its production operation. Active routes, middleware, callers, deployed schema, runtime configuration, authorization enforcement, topology, traffic, costs and operational ownership remain incomplete or unconfirmed. Compilation, test success and processing coverage do not prove semantic equivalence, security or readiness.

Existing business behaviour is therefore a compatibility constraint until characterized and explicitly accepted for preservation or change. Missing evidence is not evidence that behaviour or a consumer does not exist.

Purpose and intended outcomes

The purpose is to preserve important business capabilities while reducing the risk and lead time of change and improving security, reliability, recoverability, supportability and operational visibility. The proposal also seeks to move unsupported components onto a maintainable lifecycle, reduce key-person and supplier dependency, and enable smaller, independently verifiable releases.

No benefit baseline or approved target currently exists. Initial delivery must establish measurement before claiming improvement. Candidate indicators are:

• deployment frequency and change lead time;
• failed-change rate and restoration time;
• availability and production incident rate;
• successful backup restoration;
• unresolved security findings and unsupported dependencies;
• authorization-test coverage;
• dead-letter age and unresolved reconciliation differences.

Each adopted indicator requires an approved baseline, target, accountable owner, data source, sampling period and calculation method. Cost benefits cannot yet be stated. A future financial case should use measured current operating cost, change effort, incident cost, licence and hosting cost, supplier cost and migration cost, with savings calculated only from approved like-for-like baselines.

Current architecture and business context

The application appears to manage import, export and transit notifications; assessments and decisions; movements, shipments, receipts, rejection, recovery and disposal; parties, facilities and authorities; routes and waste classifications; guarantees, payments and refunds; files, documents, comments, audit, archives and reports.

Persistence combines relational access, repositories, raw SQL, stored procedures, direct saves, files, caches, audits and events. External dependencies appear to include identity, company lookup, payments, email, malware scanning, document conversion and reporting. Their authentication, timeout, retry, cancellation and failure contracts are not confirmed.

Import, export and transit workflows are asymmetric. Notifications, assessments, movements, shipments, receipts, guarantees and status histories are distinct concepts. These differences must not be collapsed into generic records merely to simplify the target architecture.

Preservation and change policy

Behaviours to preserve pending acceptance

Existing routes, request and response shapes, status codes, validation messages, localized text, nullability, ordering, persistence timing, navigation, audit intent and event timing should be preserved until consumers and meanings are known. Existing filenames, document formats, layouts, visible content, report columns, aliases, workbook structures and date boundaries are similarly compatibility-sensitive.

Historical reference meanings must remain distinguishable, including obsolete codes, sentinel values, “not listed” and “not applicable.” Existing user-to-business relationships and audit history must remain available. Data must not be silently deduplicated, normalized, reclassified, truncated or deleted.

Proposed changes

Mutations should reload authoritative server-side records and validate identity, ownership, organisation, authority, membership, relationships and lifecycle state. Posted or hidden identifiers must not establish authorization.

Authorization should become centrally testable against action, resource, identity and state. State-changing retrieval operations should move to protected non-GET commands only after their present behaviour and consumers are characterized.

Transactional seams, concurrency handling and durable integration should be introduced around bounded mutations. Uploads should be quarantined and scanned before promotion. Reporting may move to controlled read models where accepted freshness requirements permit.

Matters requiring resolution

Material contradictions remain in:

• submitted versus awaiting-payment state and whether awaiting payment is a state or subordinate condition;
• lifecycle transitions, terminal states, editability and actor permissions;
• receipt, partial rejection, rejection, recovery and completion precedence;
• notification and movement number scope, normalization and concurrent allocation;
• calendar-day, working-day and consent-period rules;
• quantity units, conversion, precision and rounding;
• pricing precedence, currency, tax, refunds and credit/debit interpretation;
• guarantee cardinality, supersession, release and separation of duties;
• route, facility and treatment-site cardinality;
• status, date, quantity and reference-data migration mappings.

These are decision dependencies, not defects or target requirements until accountable owners decide them.

Proposed target architecture

The proposed direction is an incremental modular architecture with compatibility adapters, explicit domain boundaries, server-side policy enforcement and defined transactional seams. The initial target should be a modular deployable, not a service-per-domain estate. A domain should be independently deployed only where evidence demonstrates a distinct scaling, security, availability, release, integration or ownership requirement.

Proposed boundaries are notification and assessment; movement and shipment; parties, organisations and locations; routes and classification; finance and pricing; guarantees; documents, files and correspondence; and reporting and audit. Cross-boundary writes should be prohibited, while physical database separation should be deferred until justified.

Azure application hosting

Azure App Service is the preferred initial candidate if the recovered runtime, operating-system dependencies and document-conversion components are supported. Azure Container Apps is a credible alternative for container-dependent workloads or independently scaled workers. Azure Functions may suit bounded schedules and asynchronous handlers.

Azure Kubernetes Service is deferred because no evidenced requirement currently justifies its operational complexity. Final selection depends on runtime recovery, networking, scaling, background work and supplier support.

Transactional data

Azure SQL Database is the leading candidate if existing SQL and stored-procedure behaviour is compatible. Azure SQL Managed Instance is a coexistence option if instance-scoped features, cross-database operations, SQL Agent or incompatible procedures are material.

A shared deployment with controlled schema ownership is preferred initially. Cosmos DB is not proposed as a default replacement for relational transactional records.

Integration and messaging

Azure Service Bus is the preferred candidate for durable commands and integration events, combined with a transactional outbox. Consumers should tolerate duplicates, and replay, retry, ordering and dead-letter ownership must be agreed. Azure Event Grid may suit lightweight notifications that do not require durable ordered processing.

Existing synchronous interfaces must remain synchronous where callers depend on immediate results. Messaging must not be presented as part of the database transaction unless that boundary is demonstrated.

Files and documents

Private Azure Blob Storage is the preferred candidate for binary content, while relational records remain authoritative for ownership and authorization. Uploads should enter quarantine and be promoted only after approved size, content, signature and malware checks.

Clean, virus, unknown, error, timeout and scanner-outage results need explicit contracts. Retention, legal hold, rescanning, cleanup, reproducibility and conversion support remain unresolved.

Identity, secrets and security

Microsoft Entra ID is the candidate workforce and service identity provider. External customer identity remains a separate decision pending discovery of the user population and account lifecycle. Managed Identities and Azure Key Vault are proposed where supported.

Bearer and cookie precedence, claims transformation, inactive-user handling, token storage, client credentials, password reset, email verification and any auto-confirmation behaviour require direct verification. Potential attacker-influenced polymorphic temporary-state deserialization requires priority investigation.

Observability and operations

Azure Monitor, Application Insights and Log Analytics are candidates for correlated metrics, traces, logs and alerts spanning requests, commands, database commits, outbox publication, message handling and external calls.

Availability, performance, support hours, retention, recovery-time and recovery-point objectives remain business and operational decisions. Service tiers must not be selected using invented thresholds. Backups require scheduled restore demonstrations.

Scope and exclusions

In scope are baseline recovery, compatibility characterization, domain and authorization contracts, server-side validation, modularisation, transaction and concurrency controls, durable integration, file security, reporting compatibility, observability, data profiling, migration rehearsal, reconciliation and recovery.

Production cutover, legacy retirement, wholesale domain redesign, service-per-domain decomposition and Azure Kubernetes Service adoption are excluded until their approval gates are met. Changes to confirmed business rules, report or document formats, historical meanings and external interfaces are excluded unless explicitly accepted.

Pricing, staffing, committed dates, outage allowances, licences and supplier charges are not established. Data residency, retention, legal hold, regulatory duties and production service levels also remain unresolved.

Delivery plan

Recover and Characterize the Executable Baseline

The first slice should establish a reproducible non-production build and deployment, authoritative inventory, controlled configuration and schema state, and one representative journey traced through identity, authorization, validation, persistence, audit, events, files or external effects.

Acceptance requires repeated deployment, successful, denied, malformed and dependency-failure observations, deployment recovery and a non-production restore demonstration. The planning range is 15, 30 or 60 elapsed working days for low, central and high scenarios.

Establish Measures and Approval Evidence

Instrument approved indicators and record human effort, automated-agent runtime, waiting time and elapsed time separately. Assign measure owners and approve baselines, targets and calculation methods.

The planning range is 8, 18 or 35 working days after baseline recovery. Remaining ranges must then be recalibrated from observed evidence.

Resolve Identity, Relationships and Authorization

Produce the action-resource-state matrix, investigate anonymous and default-allow paths, verify identity flows and activate bounded centrally testable policies. Preserve existing allowed and denied outcomes until reviewed.

The planning range is 20, 40 or 80 working days.

Formalize Lifecycles and Identifiers

Agree separate notification, assessment, movement, receipt and outcome contracts. Define identifier format, normalization, uniqueness, lookup errors and concurrency behaviour. Test stale, duplicate and simultaneous commands.

The planning range is 20, 45 or 90 working days.

Resolve Calculations and Reference Meanings

Decide date, calendar, quantity, unit, pricing, refund, guarantee, route, facility and classification contracts. Profile historical records and compare results at record level.

The planning range is 30, 65 or 130 working days.

Introduce Modular and Durable Mutation Boundaries

Move one bounded capability behind a preserved interface with a single authoritative writer, explicit transaction boundary, concurrency handling, durable integration intent and controlled activation.

The planning range is 25, 55 or 110 working days.

Secure Files and Preserve Documents

Characterize outputs, introduce private storage and quarantine controls, and test authorization, scanning, interruption, cleanup, restoration and document comparison.

The planning range is 18, 40 or 85 working days.

Establish Reporting and Operational Readiness

Automate report comparison, introduce controlled read models where appropriate, add correlated telemetry and exercise operational runbooks.

The planning range is 18, 40 or 80 working days.

Rehearse Migration, Cutover and Recovery

Profile data, execute deterministic transformations, retain rejected records, reconcile business keys and relationships, and rehearse interruption, restart, restore, message replay and controlled routing.

The planning range is 30, 70 or 150 working days. These ranges are not additive commitments; sequencing may overlap only where prerequisites, reviewers and environments permit.

Dependencies, capacity and critical path

The critical path runs through executable-baseline recovery, business-contract resolution, identity and authorization discovery, data profiling and access to external dependencies.

Scarce capacity is likely to include product and policy decision-makers, security reviewers, database specialists, finance owners, report consumers, operations staff and shared integration environments. Their availability is not established. Business calendars, change freezes, downtime allowances, source and environment access, production-like data, licences, protected sample files and supplier lead times remain explicit dependencies.

Agent activity can support inventory, comparison, test generation, profiling and discrepancy classification. Human review remains necessary for runtime evidence, business meaning, security approval, legal or policy interpretation and production authorization. Waiting time must be reported separately from active effort.

Migration, reconciliation and recovery controls

Every migration slice must define deterministic mappings, preflight diagnostics, retained rejects, checkpoints, rerun behaviour, source-to-target counts, business-key and referential reconciliation, and rollback or forward recovery.

Financial and quantity totals should be compared only where semantically valid. Documents and reports require sampled or automated output comparison. Differences must be classified and owned rather than silently corrected.

Uncontrolled dual writing should be avoided. If temporary dual writing is unavoidable, one system must remain authoritative and durable reconciliation must exist. Legacy retirement cannot proceed until callers and scheduled work are addressed, retained history remains accessible, reconciliation is accepted and retention and deletion rules are approved.

Risks and mitigations

The principal risks are incomplete baseline evidence, unproven authorization, unresolved identity exposure, contradictory business rules, unsafe file handling, non-atomic external effects, destructive migration, unknown consumers and insufficient operational ownership.

Mitigations are evidence-first delivery, deny-path testing, explicit decision records, compatibility adapters, transactional outbox patterns, quarantine, deterministic migration, record-level reconciliation, controlled activation and tested recovery. Contingency should be held as scope and sequencing flexibility rather than an invented budget or time allowance.

Approval gates

Architecture approval requires confirmed runtime and topology, domain and authorization contracts, data profiles, interface and consumer inventories, threat model, residency and retention decisions, service-level decisions, validated Azure options, operational ownership, cost assessment and demonstrated migration and recovery procedures.

Production activation additionally requires compatibility acceptance, security approval, operational runbooks, restore evidence, controlled activation criteria, measurable recovery triggers and an accepted rollback or forward-recovery plan. Until these gates are met, the target architecture and delivery scenarios remain planning hypotheses.