Startup Migrating a Monolith Under a Fixed Budget
A 14-person fintech startup runs a Java monolith on two on-premises servers in a colocation rack. The team pays roughly $3,800 per month for hardware refresh amortization, rack space, power, and a managed firewall, plus one part-time contractor at $1,200 per month for patching. Traffic is steady at 40 requests per second with a peak of 120 during weekday mornings. The CTO wants to move to AWS within one quarter to stop paying for idle capacity, but the CFO has capped cloud spending at $4,500 per month for the first year. The team has no cloud experience and is worried about losing control over security patching. Leadership is also unsure whether to re-architect the monolith into microservices now or later.
1. Should the team re-architect into microservices as part of this migration? Justify using the constraints in the scenario.
Read the worked answer
No. The scenario gives three binding constraints that argue against re-architecture now. First, the budget cap of $4,500 per month is only about $500 above current total spend, leaving almost no room for parallel running of old and new systems, which re-architecture requires. Second, the team has no cloud experience, so learning AWS and redesigning the application at the same time multiplies delivery risk. Third, traffic is modest and steady at 40 requests per second, so the monolith is not the bottleneck; idle capacity is the problem, and that is solved by right-sized cloud instances and autoscaling, not by splitting services.
The defensible path is a lift-and-shift onto managed compute with autoscaling, then incremental decomposition once the team has operational confidence and real usage data. Re-architecture is a valid later step, but treating it as a prerequisite for migration conflates two projects with different risk profiles and would likely breach the CFO's cap during the transition.
2. The CTO argues that moving to AWS automatically removes the need for the $1,200 per month patching contractor. Evaluate that claim.
Read the worked answer
The claim is only partly true, and the team should not budget as if the contractor line disappears entirely. Managed services shift some patching to AWS: if the monolith runs on managed platform services or managed databases, the provider patches the underlying host and engine. But the team still owns patching inside the guest operating system if it uses self-managed instances, plus application dependencies, TLS certificates, IAM policy hygiene, and security group review.
With zero cloud experience, the realistic outcome is a reduced but nonzero operations burden. A safer budget assumes the contractor is retained part-time for the first two quarters to cover both legacy and cloud patching, then scaled back once runbooks and automation exist. Promising the CFO a full $1,200 reduction in month one is the kind of optimistic assumption that causes a budget overrun and undermines the migration's credibility.
3. Recommend how to structure the first quarter so the $4,500 monthly cap is credible.
Read the worked answer
Sequence the work so spend tracks value. Start with a small pilot: migrate a low-risk internal workload, set up accounts, identity, logging, and a budget alert at 80 percent of the cap. Use right-sized instances with autoscaling rather than overprovisioned reserved capacity, because the team does not yet know its steady-state footprint. Keep the colocation contract alive but negotiate a shorter notice period so the two environments overlap only briefly.
Track total cost of ownership, not just the AWS bill: include support plan, data transfer out, and any retained contractor hours. Review the cap monthly against actual usage and adjust instance families before committing to savings plans. The cap is credible only if the overlap window is short and the pilot produces measured numbers that inform the full cutover.