The Lease Is Expiring: Payroll Spikes vs. a Skills-Constrained Team
A 900-person insurance firm runs a 12-year-old .NET payroll and claims application on 40 on-premises VMs, backed by SQL Server Enterprise licensed per core. Its data-center lease expires in 9 months and cannot be renewed. Payroll load spikes only during a three-day close every two weeks - roughly 8x the daily baseline - while claims traffic is flat. Regulatory rules require customer data to remain in the country, and the audit trail must be retained for seven years. The platform team is six engineers with strong Windows skills, no container or Kubernetes experience, and no budget approved for retraining this year. The CIO wants a migration plan on her desk that survives the lease deadline and does not lock the company into a design it cannot operate.
1. Recommend a migration strategy for payroll versus claims, and justify the split against the 9-month deadline and the team's skills.
Read the worked answer
Treat the deadline and the six-person team as the binding constraints, not the ideal end state.
- Payroll → rehost, unchanged. A stateful monolith with a per-core Enterprise licence will not survive a refactor in 9 months. Lift it to EC2 in-country, keep SQL Server as-is (on EC2 with licence-included or BYOL, checking host/tenancy rules before you commit), and schedule instance capacity around the close window.
- Claims → rehost, then re-platform selectively. Claims traffic is flat and well understood, so it is the better candidate for later moves to managed services (e.g., RDS for SQL Server Multi-AZ) once the team has run something in AWS.
- Do not run two migrations at once. Moving 40 VMs with six engineers is already aggressive; parallel re-architecture is how the lease date gets missed.
- Record the accepted debt. Write down explicitly which applications are 'temporary lift-and-shift' so a future team does not mistake it for a target architecture.
The judgement being tested: rehosting is not a failure here - it is the strategy that satisfies an immovable date with a team that cannot yet operate containers.
2. The CIO asks whether the 8x payroll spike justifies a serverless rewrite. Argue a position and name the conditions that would change it.
Read the worked answer
Position: no, not for the whole application - but yes for fragments of it.
- Packaging for Lambda caps execution at 15 minutes and the team has no container experience; a rewrite would consume the entire runway and deliver nothing by the lease date. The risk is asymmetric.
- More importantly, elasticity does not solve the spike: the bottleneck is the relational database holding payroll state. Compute can scale to zero between closes, but the database still needs peak-provisioned capacity, so the 8x spike is largely unavoidable cost regardless of compute model.
Conditions that would flip the answer:
- If discrete, stateless stages can be isolated - PDF generation, payslip rendering, report exports - extract those to queue-plus-function designs; they inheriting elasticity without touching the core.
- If the business can accept a phased retirement of the monolith over 2–3 years with funded retraining.
- If the database is re-platformed first to something that scales with the compute layer.
The exam-style trap is treating 'peak load exists' as automatic proof of 'use serverless'; the real question is where the bottleneck sits.
3. How do the in-country data rule and the seven-year retention requirement constrain the design, and what decision should be recorded?
Read the worked answer
These requirements shrink the option space more than any technology preference:
- Region choice is fixed, not optimised. Pick the in-country region and treat it as a hard constraint; cross-region replication or a DR copy in a different country is off the table unless legal clears it in writing.
- Availability comes from Availability Zones, not regions. The only resilience lever left is multi-AZ within the approved region. Say so plainly to the CIO: the achievable RPO/RTO is lower than a true multi-region design, and that is a business acceptance, not an engineering one.
- Retention is a storage-class and immutability question. Seven-year audit retention points to archival tiers plus a lock/immutability control applied at write time, with retrieval costs modelled for the rare audit. Cheapest storage that cannot be deleted is the goal, not cheapest storage.
- Record it as an architecture decision: 'single approved region; DR limited to multi-AZ; no cross-border replication; audit data immutable for seven years.' Six months from now someone will propose a second region to cut latency, and this record is what stops the argument restarting.