This is a fictional but realistic completed Solution Architecture Document at Recommended depth. It demonstrates how to document an on-premises to cloud migration using ADS, with particular emphasis on:
Section 1.5 — Current-state / as-is architecture for a legacy system
Section 5.2 — Migration classification (6 R’s) and transition planning
The fictional company “Meridian Financial Services” is migrating its legacy HR/Payroll system “PayrollPro” from on-premises Windows Server infrastructure to Microsoft Azure.
This SAD describes the target-state architecture for migrating the PayrollPro application from on-premises hosting to Microsoft Azure. It covers the re-platforming of the web application tier, database tier, and document storage, alongside the transitional connectivity required during the migration period.
In scope:
PayrollPro web application and database migration to Azure
Data migration strategy and cutover plan
Transitional VPN connectivity between on-premises and Azure
Integration continuity with BACS, pension provider, and HMRC
Out of scope:
Citrix VDI replacement (deferred to Phase 2)
Application refactoring to microservices (deferred to Phase 2)
Other HR systems (recruitment portal, learning management)
PayrollPro is the primary payroll processing system for Meridian Financial Services, serving approximately 2,400 employees across six UK offices. The application processes monthly payroll runs, generates payslips, submits PAYE data to HMRC, and interfaces with the corporate pension provider and BACS payment gateway.
The current on-premises hosting infrastructure is approaching end of life (Dell PowerEdge R630 servers purchased in 2017, Windows Server 2016 reaching end of extended support). This project migrates PayrollPro to Microsoft Azure using a Replatform strategy — upgrading the application runtime from .NET Framework 4.8 to .NET 6 and moving the database from SQL Server 2017 on bare metal to Azure SQL Database. This approach delivers improved reliability, disaster recovery, and operational efficiency whilst deferring a full architectural refactoring to a later phase.
PayrollPro was originally developed in 2014 as an ASP.NET Web Forms application on .NET Framework 4.5, subsequently upgraded to .NET Framework 4.8 in 2020. It is deployed on-premises in the Meridian London datacentre (Docklands).
No disaster recovery — Single-site deployment with no replication. Estimated recovery time from backup is 24-48 hours. A total server failure during payroll week would breach statutory payment deadlines.
Month-end performance — The payroll calculation batch takes 5-7 hours on current hardware. If errors are found, there is insufficient time to re-run before the BACS submission deadline.
Manual patching — All Windows and SQL Server patching is performed manually during weekend maintenance windows. Average 3 days per month of DBA/infrastructure engineer time.
Hardware risk — Servers are 9 years old with no warranty. Two disk failures in the past 12 months, resolved from diminishing spare stock.
No network segmentation — Application and database tiers share a flat VLAN, contrary to Meridian’s updated security standards.
Limited monitoring — SCOM provides basic threshold alerts only. No application performance monitoring, no structured logging, no capacity trending.
Service failure causes immediate, severe business impact
Tier 2: High Impact
Service failure significantly impacts business operations
Tier 3: Medium Impact
Service failure impacts operations but workarounds exist
Tier 4: Low Impact
Service failure has limited business impact
Tier 5: Minimal
Service failure has negligible impact
Selected criticality: Tier 2 — High Impact
PayrollPro is classified as Tier 2 because a prolonged outage during the payroll processing window (typically days 22-25 of each month) would prevent statutory salary payments to 2,400 employees. Outside the payroll window, a short outage is tolerable (employee self-service and reporting can wait). The system does not directly process financial transactions in real time (Tier 1), but failure to pay staff on time carries significant legal, reputational, and employee welfare consequences.
Yes — Staging environment connects to BACS sandbox and HMRC test gateway for integration testing. Production and non-production environments do not share any other connectivity.
Azure UK South (London) primary and UK West (Cardiff) DR — both chosen for data residency. Microsoft has committed to 100% renewable energy matching across UK regions by 2025. Cardiff’s published grid mix is cleaner than London on average.
Non-production environments auto-shutdown out of hours
Yes — Dev and UAT App Service plans set to free-tier-equivalent off-hours via Azure Automation runbook (19:00-07:00 weekdays + weekends). Non-prod Azure SQL auto-paused after 1 hour idle. Estimated saving £600/month.
Compute family chosen for performance-per-watt
Yes — Premium v3 App Service Plan SKUs (Pv3) selected over Pv2; Microsoft published data shows ~25% better performance-per-watt and faster warm-up. Azure SQL Business Critical tier uses latest-generation hardware.
Auto-scaling configured to release capacity when idle
Yes — App Service Plan auto-scale rules: scale-out at >70% CPU for 10 min; scale-in at <30% CPU for 20 min; minimum 2 instances during business hours, 1 instance overnight.
DR strategy proportionate to recovery objective
Pilot light: Azure SQL geo-replica is read-only and continuously replicated; App Service in UK West is deployed on-demand via Bicep IaC during DR invocation. RTO 4 hours, RPO 15 minutes. Hot standby was rejected as the business RTO does not justify doubling the always-on compute footprint.
Restricted/Highly Restricted attributes are deleted first
Sensitive data is masked (describe method below)
[x]
Sensitive production data is used (provide justification below)
Production data is not used for testing
Staging environment uses a masked copy of production data. Masking is applied via a custom SQL script that replaces NI numbers with generated values (format-preserving), randomises salary figures within bands, and replaces bank details with test account numbers. Names and addresses are replaced with synthetic data from Faker.js. The masked dataset is refreshed quarterly.
Yes — Payroll calculation checksums are computed and stored alongside each payroll run. Reconciliation reports compare calculated totals against BACS submission totals and pension contribution totals. Any discrepancy triggers an alert and blocks submission.
Yes — Employees can download their own payslip PDFs via the self-service portal (accessed through Citrix). Payslips are downloaded to the Citrix session local drive only; data-loss prevention policies prevent copying to personal devices.
Yes — All payroll data must reside within the United Kingdom. Azure SQL Database and Blob Storage are deployed in UK South (London) and UK West (Cardiff) regions only. Geo-replication is restricted to UK regions. Azure backup vaults are configured for UK geo-redundancy only.
Retention periods minimised to regulator + business need
Yes — payroll data and payslips retained 7 years (HMRC requirement); audit logs 7 years; transient session data ≤ 24 hours. Lifecycle policies on Blob Storage enforce automatic expiry; no “indefinite” retention.
Older data tiered to cold/archive storage
Yes — Blob Storage lifecycle policy: Hot tier for the current tax year, Cool tier for years 2-3, Archive tier for years 4-7. ~80% of payslip storage sits in Cool/Archive.
Unused or duplicate replicas identified and removed
Yes — quarterly review of Azure SQL replica count (currently primary + 1 DR replica only). No legacy unused storage accounts; verified via Azure Advisor recommendations.
Compression applied to reduce storage and transfer
Yes — gzip on payslip PDFs at upload (~40% reduction); HTTPS responses use Brotli. SSIS packages use bulk insert with compression enabled.
Cross-region replication justified by recovery requirement
Yes — only Azure SQL geo-replica and Blob Storage RA-GRS replicate to UK West. Both are required by the documented RPO (15 min) and DR strategy. No replication to non-UK regions.
Large data transfers scheduled to off-peak windows
Yes — monthly payroll batch and HMRC RTI submissions run between 02:00-05:00 UTC; nightly database backups run 23:00-01:00 UTC; both off-peak from a UK grid carbon intensity perspective.
App Service deployed with VNet Integration into dedicated subnet; Azure SQL and Blob Storage accessible only via Private Endpoints; NSGs restrict traffic to required flows only
Ingress filtering
App Service access restrictions: allow only from Meridian hub VNet (Citrix subnet and VPN). No public access.
Egress filtering
App Service subnet uses UDR to route Internet-bound traffic through Azure Firewall in hub VNet; allowed destinations: BACS SFTP endpoint, Crestfield API, HMRC API
Encryption in transit
TLS 1.2 minimum enforced on all endpoints; App Service configured with minimum TLS 1.2; Azure SQL enforces encrypted connections
Scheduled monthly payroll processing date (typically day 22 of each month)
Pre-conditions
All employee data changes for the month have been entered and approved; tax code updates from HMRC have been imported
Main Flow
1. Payroll Operator logs in via Citrix, authenticated by Entra ID (MFA). 2. Operator initiates payroll run via PayrollPro UI. 3. Payroll Batch Processor (Azure WebJob) executes on App Service, reading employee and configuration data from Azure SQL. 4. Batch calculates gross pay, tax deductions (PAYE), NI contributions, pension deductions, student loan repayments for all 2,400 employees. 5. Payslip PDFs are generated and stored in Azure Blob Storage. 6. BACS Standard 18 payment file is generated. 7. Operator reviews summary report and approves. 8. BACS file is submitted via SFTP. 9. HMRC FPS is submitted via Government Gateway API. 10. Pension contributions are submitted to Crestfield via REST API.
Post-conditions
All employees paid; HMRC notified; pension contributions submitted; payslips available in self-service portal; audit trail recorded
Views Involved
Logical, Integration & Data Flow, Physical, Data, Security
UC-02: New Starter Onboarding
Attribute
Detail
Actor(s)
HR Administrator
Trigger
New employee joining Meridian
Pre-conditions
Employee has accepted offer; Entra ID account created by IT; employee added to PayrollPro security group
Main Flow
1. HR Administrator logs in via Citrix, authenticated by Entra ID (MFA). 2. Administrator creates new employee record in PayrollPro: personal details, contract terms, salary, tax code, bank details, pension opt-in. 3. Bank details and NI number are encrypted at field level before storage (AES-256-GCM via Key Vault). 4. Employee is included in the next payroll run. 5. Employee gains access to self-service portal via Entra ID group membership.
Post-conditions
Employee record created with all required fields; SPI encrypted; employee visible in next payroll run; self-service access available
PayrollPro must be migrated from on-premises to Azure before hardware end of life (Dec 2026). The team evaluated Rehost (lift-and-shift to Azure VMs) versus Replatform (upgrade to .NET 6, deploy to App Service and Azure SQL).
Decision
Replatform — upgrade the application to .NET 6 and deploy to Azure PaaS services (App Service + Azure SQL Database).
Alternatives Considered
(1) Rehost to Azure VMs: Lower initial effort but perpetuates manual patching burden, does not address performance issues, and incurs higher ongoing IaaS costs. (2) Refactor to microservices: Best long-term architecture but timeline exceeds hardware EOL deadline; estimated 18+ months vs. 10 months for replatform. (3) Replace with SaaS payroll: Evaluated Workday and ADP; neither met Meridian’s bespoke BACS and pension integration requirements without significant customisation and data migration risk.
Consequences
Positive: Managed patching, built-in geo-replication, auto-scaling, reduced OpEx. Negative: .NET 6 upgrade requires development effort (~6 weeks); some legacy stored procedures must be reworked for Azure SQL compatibility.
The database tier could be deployed as SQL Server on an Azure VM (IaaS) or as Azure SQL Database (PaaS). The DBA team raised concerns about Azure SQL compatibility with existing T-SQL features.
Decision
Use Azure SQL Database (Business Critical tier) as the primary data store.
Alternatives Considered
(1) SQL Server on Azure VM: Full SQL Server feature parity but requires manual patching, backup configuration, and HA setup (Always On Availability Groups). (2) Azure SQL Managed Instance: Closer to on-prem feature parity than Azure SQL DB but higher cost and slower provisioning; features not needed by PayrollPro.
Consequences
Positive: Built-in automated backups (PITR 35 days), geo-replication, automatic patching, zone redundancy. Negative: SQL Agent jobs must be replaced with Azure Data Factory or WebJobs; some cross-database queries must be refactored; DBA team requires Azure SQL training.
Quality Attribute Tradeoffs
Improves: Reliability (built-in HA and DR), Operational Excellence (automated patching and backups). Cost: Lower than SQL on VM (no Windows Server licensing). Trade-off: Some DBA flexibility reduced vs. full SQL Server instance.
ADR-003: Retain Citrix in Phase 1
Field
Content
Status
Accepted
Date
2026-02-05
Context
PayrollPro is currently accessed exclusively via Citrix XenApp. Migrating both the application and the access method simultaneously increases risk and extends the timeline.
Decision
Retain Citrix access for Phase 1. Users will access the Azure-hosted PayrollPro via Citrix, routed through a site-to-site VPN. Phase 2 will replace Citrix with direct browser access or Azure Virtual Desktop.
Alternatives Considered
(1) Direct browser access from Phase 1: Eliminates Citrix dependency but requires WAF deployment, public endpoint exposure, and additional security review — adding 6-8 weeks. (2) Azure Virtual Desktop from Phase 1: Replaces Citrix but is a separate infrastructure project with its own timeline and budget.
Consequences
Positive: Reduces migration scope and risk; maintains familiar user experience. Negative: Requires transitional VPN; Citrix becomes a dependency and single point of access; VPN adds latency for Azure-hosted application.
Quality Attribute Tradeoffs
Performance: Slight increase in latency due to VPN hop (estimated +10-20ms, acceptable). Reliability: Citrix and VPN become dependencies; mitigated by existing Citrix HA. Cost: VPN Gateway adds ~£250/month.
Is the application deployed across multiple hosting venues for continuity?
Yes — Azure SQL geo-replicated from UK South to UK West. App Service can be deployed to UK West via IaC within 30 minutes.
What is the DR strategy?
Warm Standby (database) / Pilot Light (application). Azure SQL active geo-replication provides a read-only replica in UK West. App Service is deployed on-demand via Bicep templates stored in Azure DevOps.
Are there data sovereignty requirements affecting geographic choices?
Yes — UK data residency required. Both primary (UK South) and DR (UK West) regions are within the United Kingdom.
App Service auto-scales from 2 to 5 instances based on CPU utilisation (threshold: 70%) and HTTP queue length (threshold: 100). Scale-out is triggered during month-end payroll processing. Scale-in occurs after batch completion. Azure SQL is provisioned at 8 vCores (Business Critical); manual scale-up to 16 vCores available if needed (tested, takes < 2 minutes with no downtime).
BACS SFTP gateway and HMRC API are externally managed services with documented rate limits (BACS: no limit for Standard 18 files; HMRC: 1,000 requests/hour). Crestfield API has a 500 requests/hour limit, sufficient for monthly batch of ~2,400 records.
Component failures: App Service runs on minimum 2 instances; if one instance fails, traffic is routed to the healthy instance. Azure SQL Business Critical tier includes built-in local HA (3 replicas).
Graceful degradation: If Blob Storage is temporarily unavailable, payslip viewing returns an informative error but payroll processing continues. If a third-party API (BACS, HMRC, Crestfield) is unavailable, the submission is queued and retried with exponential backoff (3 retries, 5/15/60 minute intervals).
Health checks: App Service health check endpoint (/health) validates database connectivity and Key Vault access. Unhealthy instances are automatically removed from the load balancer.
Will the current design scale to accommodate projected growth?
Yes — App Service auto-scaling to 5 instances and Azure SQL 8 vCores are sufficient for projected 5-year growth. Azure SQL can be scaled to 16 vCores without downtime if needed.
Are there known seasonal or cyclical demand patterns?
Yes — Significant peak during monthly payroll window (days 22-25). Additional peaks at tax year end (April) for P60 generation.
Design decisions chosen for specific reasons other than cost
[x]
Azure SQL Business Critical tier selected for built-in HA and zone redundancy, despite being more expensive than General Purpose. This decision is driven by the Tier 2 reliability requirement.
Most cost-effective options intentionally not selected
[x]
Azure SQL Serverless was evaluated for production but rejected due to cold-start latency incompatible with payroll batch SLA. Used for dev environment only.
Most cost-effective options selected
[x]
Blob Storage LRS (not GRS) selected for primary payslip storage; geo-redundancy provided via Azure Backup vault at lower cost than GRS.
Yes — Azure Pricing Calculator used to model production and non-production costs. TCO comparison performed against on-premises refresh cost (new Dell servers + 3-year licensing + datacentre costs).
Key findings: Azure monthly OpEx (£4,200) is approximately 30% lower than annualised on-premises TCO (£72,000/year including hardware refresh, licensing, datacentre hosting, and patching labour). Break-even on migration capex (£185,000) is reached within 3 years.
No — The design fully meets requirements; cost has not constrained the design. The Business Critical Azure SQL tier was selected despite higher cost to meet reliability requirements.
Has the hosting location been chosen to reduce environmental impact?
Partially — UK South and UK West were selected primarily for data sovereignty. Microsoft Azure UK regions are powered by a mix of renewable and non-renewable energy; Microsoft has committed to 100% renewable energy by 2025.
What is the expected workload demand pattern?
Variable — significant peak during monthly payroll window (days 22-25); low utilisation remainder of month
Yes — production must be available during business hours (07:00-20:00 UK). Out-of-hours access is required for month-end payroll runs.
Can the solution be shut down or scaled down during off-peak hours?
Partially — App Service scales down to 2 instances outside peak periods via auto-scaling rules. Cannot be fully shut down due to employee self-service access.
Are non-production environments configured to downscale or shut down when not in use?
Yes — Dev environment uses Azure SQL Serverless (auto-pause after 1 hour inactivity). Staging App Service scaled to 0 instances outside working hours via scheduled scaling rules.
Are resources rightsized to avoid overprovisioning?
Yes — App Service tier (P2v3) and Azure SQL vCores (8) sized based on performance testing of production-equivalent payroll batch. Auto-scaling ensures minimum instances during quiet periods.
Is vCPU utilisation monitored?
Yes — target average utilisation of 40-60% at steady state, rising to 70-80% during month-end peak (scaling trigger at 70%).
Are the highest performance-per-watt hardware options used?
Azure manages underlying hardware selection. P2v3 plan uses latest-generation Dv3 series VMs with good performance-per-watt characteristics.
Yes — PayrollPro includes internally developed software (the web application and batch processing components).
Attribute
Detail
Source control platform
Azure DevOps Repos (Git)
CI/CD platform
Azure DevOps Pipelines
Build automation
Automated build triggered on push to main branch; NuGet restore, .NET 6 build, unit tests, code coverage report
Deployment automation
Azure DevOps release pipeline with stages: Build -> Deploy to Dev -> Deploy to Staging (manual gate) -> Deploy to Production (manual gate with approval)
Test automation
Unit tests (xUnit, ~85% coverage), integration tests (run against staging), SCA (NuGet Audit), SAST (SonarQube)
Keep as-is, not suitable for migration at this time
Retire
Decommission; functionality no longer needed
Rehost
Lift-and-shift to new infrastructure with minimal changes
Replatform
☑
Lift-and-shift with targeted optimisations: .NET Framework 4.8 upgraded to .NET 6; SQL Server on bare metal migrated to Azure SQL Database; file share migrated to Azure Blob Storage
Refactor
Re-architect components to take advantage of new platform capabilities (deferred to Phase 2)
Replace
Replace entirely with a new solution (evaluated and rejected — see ADR-001)
Blue-Green. Production traffic remains on the on-premises system until cutover. Azure environment is fully deployed and validated in parallel. Cutover switches Citrix published app to the Azure endpoint.
Data migration mode
Phased
Data migration method
Azure Database Migration Service (DMS) for online migration with continuous sync. Initial full backup restore, then continuous replication of transaction log changes until cutover. Payslip files migrated via AzCopy from on-premises file share to Azure Blob Storage.
Data volume to migrate
Database: ~100 GB. Blob (payslips): ~180 GB.
End-user cutover approach
One-off. All users switch to the Azure-hosted application simultaneously via Citrix published app update.
External system cutover
One-off. BACS SFTP endpoint, HMRC API credentials, and Crestfield API credentials updated to originate from Azure.
Maximum acceptable downtime
4 hours (scheduled weekend maintenance window)
Rollback plan
On-premises servers retained for 30 days post-cutover. If critical issues found within rollback window: (1) Stop DMS continuous sync. (2) Revert Citrix published app to on-premises endpoint. (3) Apply any transactions from Azure SQL back to on-premises SQL Server via DMS reverse sync. Rollback tested during rehearsal.
Acceptance criteria
(1) All payroll data verified via reconciliation checksums. (2) Test payroll run completes successfully on Azure. (3) BACS test file submitted to sandbox. (4) HMRC test submission accepted. (5) Performance test confirms batch completes in < 2 hours. (6) DR failover test completed. (7) Payroll Team Lead sign-off.
Transient infrastructure needed?
Yes — Azure DMS instance (Standard tier, 4 vCores) provisioned for duration of migration (estimated 2 weeks). Decommissioned after cutover validation. On-premises servers retained for 30-day rollback window.
Monthly (aligned with post-payroll window; releases deployed in first week of each month to avoid payroll disruption)
Release process
Feature branches merged to main; automated CI/CD pipeline deploys to Dev, then Staging (manual approval), then Production (manual approval with change ticket)
Release validation
Smoke tests run automatically post-deployment; payroll team validates key functions in staging before production approval
Feature flags / toggles
Not currently used; to be evaluated for Phase 2 refactoring
Level 1: IT Service Desk (ServiceNow). Level 2: IT Operations (infrastructure and platform). Level 3: Payroll Development Team (application defects). DBA Team (database issues).
Support hours
Business hours (08:00-18:00 UK) with on-call escalation for P1/P2 incidents during payroll window (days 22-25 of month)
Dev and UAT App Service plans scaled-in to F1 (free) tier 19:00-07:00 weekdays + weekends via Azure Automation runbook; non-prod Azure SQL auto-pauses after 1 hour idle. Azure Policy alerts FinOps if a non-prod resource runs without a tag/exception.
Periodic right-sizing review cadence
Quarterly via Azure Advisor; last review (2026-Q1) downgraded the staging App Service Plan from P1v3 to P0v3, recovering ~£90/month.
Unused / orphaned resource reclamation
Monthly review of orphaned managed disks, unattached public IPs, stale snapshots; deleted after 30 days idle if no exception recorded.
Carbon footprint reported alongside cost
Yes — Azure Emissions Impact Dashboard reviewed monthly alongside cost; tracked against a 2026 baseline established during migration cutover.
Can the team fully operate and support this solution in production?
B: Partially capable — team has strong on-premises skills but limited Azure operational experience
If B, C, or D: what additional resources are required?
Azure platform training (see above); 3-month engagement with Microsoft FastTrack for hands-on migration support; Meridian Cloud Centre of Excellence available for advisory support
Is a managed service being considered for ongoing operations?
No — Meridian IT Operations will manage the solution with PaaS reducing operational burden
.NET 6 LTS supported until November 2027; upgrade to .NET 8 LTS planned for 2027. Azure SQL patched automatically by Microsoft.
Hardware lifecycle management
N/A — PaaS deployment; no hardware to manage
Certificate management
BACS SFTP certificate stored in Key Vault with 30-day expiry alert. TLS certificates managed by Azure App Service (managed certificates for custom domains).
Dependency management
NuGet packages reviewed quarterly; SCA (NuGet Audit) runs on every build; critical vulnerabilities patched within 7 days
Application is standard ASP.NET Core; can be deployed to any container host or IaaS. Database is standard T-SQL; exportable via BACPAC. Blob data exportable via AzCopy.
Data portability
Azure SQL supports BACPAC export for full schema and data. Blob Storage supports AzCopy for bulk data transfer. All encryption keys are customer-managed and exportable.
Vendor lock-in assessment
Moderate — see Section 3.1.6. Primary lock-in is Azure SQL managed features (geo-replication, automated backups) which would need replacement on another platform. Application code has no Azure-specific SDK dependencies.
Exit timeline estimate
3-6 months to migrate to an alternative cloud or on-premises platform, including database export, application redeployment, and integration reconfiguration
Data migration via DMS causes data loss or corruption
Technical
High
Low
Claire Doe
R-003
Azure SQL performance for payroll batch is worse than on-premises SQL Server
Technical
Medium
Low
Claire Doe
R-004
DBA resource availability — Claire Doe is single point of expertise for PayrollPro database
Delivery
High
Medium
Polly Doe
R-005
VPN connectivity instability between Azure and on-premises during Citrix access
Technical
Medium
Low
Joe Bloggs
R-006
Entra ID Connect deployment delayed beyond June 2026
Delivery
High
Low
Joe Bloggs
Risk response:
ID
Mitigation Strategy
Mitigation Plan
Residual Risk
Last Assessed
R-001
Mitigate
Parallel payroll run in staging with reconciliation against on-premises results for 2 months before cutover; comprehensive unit and integration tests for calculation engine
Low
2026-03-15
R-002
Mitigate
DMS migration rehearsal with full data reconciliation (row counts, checksums, sample verification); rehearsal scheduled for Aug 2026
Low
2026-03-15
R-003
Mitigate
Performance testing on Azure SQL with production-scale data; Azure SQL can be scaled up (8 -> 16 vCores) within minutes if needed
Low
2026-03-15
R-004
Mitigate
Cross-train second DBA (Amir Patel) on PayrollPro database; document all migration procedures in runbook
Medium
2026-03-15
R-005
Mitigate
VPN tested and proven stable (A-002). Monitoring and auto-reconnect configured. Emergency fallback: enable temporary public access to App Service with IP restrictions.
Low
2026-03-15
R-006
Mitigate
PayrollPro migration plan has Entra ID Connect as a dependency; regular check-ins with IAM project team; fallback: temporary Azure AD-only authentication without on-prem sync
Does the design materially change the organisation’s technology risk profile?
No — the migration improves the risk profile by adding DR capability, eliminating hardware EOL risk, and improving security posture (network segmentation, managed patching, field-level encryption)
If yes, has this been evaluated with Risk and Controls teams?
Point-In-Time Restore — Azure SQL feature allowing database restoration to any point within the retention period
Replatform
A migration strategy that moves a workload to a new platform with targeted optimisations (e.g., adopting managed database services) without re-architecting the application
RTI
Real Time Information — HMRC system requiring employers to report payroll data in real time
Standard 18
The BACS file format specification for payment instruction files
TDE
Transparent Data Encryption — SQL Server and Azure SQL feature that encrypts data at rest
Strong business context, current state well-documented, strategic alignment demonstrated. Scored 4 not 5: reuse assessment could include more detail on rejected platforms.
3.1 Logical View
3
Fred Bloggs
2026-03-28
Components documented with technology choices; vendor lock-in assessed. Scored 3 not 4: component interactions could be more formally specified (e.g., API contracts between modules). Monolithic architecture limits decomposition detail.
3.2 Integration & Data Flow
4
Fred Bloggs
2026-03-28
All internal and external integrations documented with protocols and authentication. End user access documented.
All data stores classified, retention and encryption specified, PII/SPI identified, data sovereignty addressed, data transfers documented.
3.5 Security View
4
Jane Doe
2026-03-28
Business impact assessed, authentication and authorisation fully documented, encryption at rest and in transit specified, secrets management documented, SIEM integration confirmed. Scored 4 not 5: formal threat model (STRIDE) not yet completed.
3.6 Scenarios
3
Fred Bloggs
2026-03-28
Key use cases documented with flows; ADRs capture significant decisions with rationale and alternatives. Scored 3 not 4: use cases could cross-reference views more explicitly.
4.1 Operational Excellence
3
Joe Bloggs
2026-03-28
Centralised logging, monitoring, and alerting in place. Scored 3 not 4: operational runbooks not yet fully documented (in progress).
4.2 Reliability
4
Fred Bloggs
2026-03-28
DR strategy documented with RTO/RPO targets, backup configured with immutability, auto-scaling defined, fault tolerance designed with failure modes.
4.3 Performance
3
Fred Bloggs
2026-03-28
Targets defined, growth projected. Scored 3 not 4: performance testing not yet executed (planned for May-Jun 2026).
4.4 Cost Optimisation
3
Polly Doe
2026-03-28
Cost analysis performed using Azure Pricing Calculator, TCO comparison documented. Scored 3 not 4: FinOps practices (tagging, rightsizing reviews) not yet formalised.
CI/CD documented, migration plan detailed with 6 R’s classification, phased timeline, rollback plan, skills assessment with training plan. Strong migration section.
6. Decision Making
3
Fred Bloggs
2026-03-28
Constraints, assumptions, risks, and dependencies documented with ownership. ADRs captured. Scored 3 not 4: some assumptions still open; compliance traceability not yet complete.
Overall
3
Fred Bloggs
2026-03-28
Weakest-link scoring. Multiple sections at 3 reflect the pre-go-live state: operational runbooks, performance testing, and FinOps practices are in progress and will improve scores to 4 before production approval.
