The Technical Memo That Prevented a Cloud Migration
The Technical Memo That Prevented a Cloud Migration
The Setup
Sarah Chen had been a Staff Engineer at a mid-sized fintech company for two years when the new CTO arrived with a clear mandate: “We’re moving everything to the cloud within 18 months.” The announcement came with a $12M budget, a detailed timeline, and executive enthusiasm. Three consulting firms submitted proposals. The migration project was presented as a done deal.
Sarah had a problem. She didn’t think it was the right move.
The Dilemma
The company ran a high-frequency trading platform processing millions of transactions per second with sub-millisecond latency requirements. Their entire infrastructure was built on colocated bare metal servers with custom network configurations, FPGA-accelerated processing, and direct connections to exchanges.
The proposed cloud migration promised “improved agility,” “reduced operational overhead,” and “better scalability.” But Sarah’s back-of-the-envelope calculations suggested the cloud architecture would increase their transaction latency by 5-10x and cost 3-4x more annually than their current setup.
She faced a classic Staff Engineer challenge: how do you stop a high-momentum, executive-sponsored initiative based on technical analysis that contradicts the prevailing narrative?
The Wrong Approach
Sarah’s initial instinct was to voice concerns in meetings. She tried:
- Pointing out latency issues in the all-hands Q&A (dismissed as “early concerns we’ll address in the design phase”)
- Raising cost projections in the architecture review (met with “cloud costs always optimize over time”)
- Questioning the timeline in a 1-on-1 with her director (told “the decision is made, we need to focus on execution”)
Each attempt positioned her as the naysayer blocking progress. The social cost was mounting, and her concerns weren’t being heard because they came as reactive objections rather than proactive analysis.
The Turning Point
Sarah’s manager gave her crucial advice: “If you think this is wrong, write it down. Make the case so clear that people can’t ignore it.”
She spent a weekend crafting a technical memo. Not a quick email, not a Slack message—a comprehensive, data-driven document. The structure was deliberate:
1. The Steel Man (Not Straw Man)
Sarah opened by presenting the strongest possible case FOR cloud migration:
- Reduced need for hardware refresh cycles
- Faster provisioning for new services
- Access to managed services (databases, message queues, ML platforms)
- Geographic distribution for disaster recovery
- Alignment with industry trends
She didn’t dismiss these benefits. She acknowledged them fully. This established credibility—she wasn’t blindly opposed; she’d done the homework.
2. The Performance Analysis
She built a detailed performance model comparing their current architecture to proposed cloud equivalents:
Current system:
- P99 latency: 247 microseconds
- Direct 10Gb fiber to exchanges
- FPGA-accelerated order matching
- NVMe storage with kernel bypass I/O
Proposed cloud system:
- P99 latency (projected): 2.1 milliseconds
- Shared network infrastructure
- CPU-based matching (even with optimized instances)
- Network-attached storage
The key insight: their competitive advantage came from being in the 99th percentile of execution speed. Moving to cloud would push them to median performance among competitors.
3. The Real Cost Analysis
The consulting proposals showed cloud costs decreasing over time. Sarah showed they’d increase:
Year 1: $8M (current datacenter) vs. $11M (cloud with reserved instances) Year 3: $8.5M (current) vs. $18M (cloud, accounting for actual usage growth and egress costs) Year 5: $9M (current) vs. $24M (cloud)
She included line items the proposals omitted: egress costs for market data, data transfer between availability zones, sustained compute for latency-sensitive workloads that can’t use spot instances.
4. The Alternative Proposal
This was the crucial section. Sarah didn’t just say “don’t migrate.” She proposed a hybrid approach:
Keep on bare metal:
- Core trading engine
- Order matching system
- Real-time risk calculations
- Market data ingestion
Move to cloud:
- Customer-facing web applications
- Reporting and analytics
- Back-office systems
- Development and testing environments
She estimated this would capture 60% of the cloud migration benefits while maintaining performance and costing $6M less over five years.
5. The Reversibility Analysis
Sarah added a critical dimension: what happens if we’re wrong?
If we DON’T migrate and should have: We can still migrate the necessary pieces. Cost: delayed benefits for 12-18 months.
If we DO migrate and shouldn’t have: Extremely expensive to reverse. Cost: $15M+ migration costs plus 3-5 years of elevated operational costs before we could justify moving back.
She framed this as a one-way door vs. two-way door decision, making the risk asymmetry clear.
The Response
Sarah shared the memo first with her direct manager, then with the VP of Engineering, and finally requested it be circulated to the executive team. The CTO read it over a weekend.
Monday morning, he called a meeting with Sarah, the VP of Engineering, and the consulting firm representatives. The conversation lasted four hours. Sarah walked through her analysis. The consultants pushed back on her latency projections and cost estimates.
The turning point came when the CTO asked: “Can you guarantee sub-millisecond P99 latency in the proposed architecture?”
After significant hedging, the answer was: “Not with the current proposal, but we could architect something custom.”
“At what cost?” asked the CTO.
“We’d need to scope that, but likely $4-5M additional spend on dedicated infrastructure and direct network connections.”
The CTO did the math: $12M base migration + $5M performance architecture + $6M annual cost increase vs. $6M for the hybrid approach. The decision became obvious.
The Outcome
The company adopted Sarah’s hybrid proposal. Three years later:
Business outcomes:
- Trading engine maintained competitive latency
- Development velocity increased 40% (cloud-based dev/test environments)
- Customer application deployment time reduced from weeks to hours
- Total infrastructure costs grew 15% instead of the projected 180%
Career outcomes for Sarah:
- Promoted to Principal Engineer 14 months later
- The memo became a template for technical decision-making at the company
- She established credibility as someone who could challenge executive initiatives with data
- Other teams began requesting her input on major architectural decisions
Lessons for Staff Engineers
1. Written Analysis Scales Influence
Verbal objections in meetings are ephemeral and easily dismissed. Written analysis can be shared, referenced, and discussed asynchronously. It forces readers to engage with the substance of your argument.
2. Steel Man Your Opponents
The fastest way to lose credibility is to dismiss the benefits of the position you’re arguing against. Acknowledge valid points. Your analysis becomes much stronger when you say “Yes, AND here’s what we’re missing” rather than “No, BECAUSE you’re wrong.”
3. Data Beats Intuition
“I don’t think this will work” is unconvincing. “This will increase P99 latency by 8.5x based on the following model” is hard to argue with. Invest time in quantitative analysis.
4. Always Provide Alternatives
Pure negation is not leadership. If you’re arguing against a proposal, you must provide a concrete alternative. Sarah didn’t just say “don’t migrate”—she designed a hybrid approach that captured most benefits while avoiding the core risks.
5. Frame Risk Appropriately
Reversibility matters. A bad decision you can back out of is very different from a bad decision that locks you in for years. Making this explicit helps executives understand the real stakes.
6. Timing and Distribution Matter
Sarah didn’t ambush the executives. She shared her analysis with her manager first, incorporating feedback before wider distribution. She requested the right forums rather than demanding them. Process matters.
7. Be Prepared to Be Wrong
Sarah ended her memo acknowledging the limits of her analysis: “This represents my best understanding based on current information. I could be wrong about latency impacts or cost trajectories. I believe the hybrid approach reduces our risk if my analysis is incorrect.”
Intellectual humility strengthens technical arguments. It shows you’re optimizing for the right decision, not for being right.
The Broader Pattern
This story illustrates a critical Staff Engineer skill: influencing technical direction through artifacts, not authority. Sarah had no organizational power to stop the cloud migration. She couldn’t mandate a different approach. Her tool was a well-reasoned document that made the tradeoffs impossible to ignore.
The memo did several things simultaneously:
- Demonstrated deep technical expertise
- Showed business acumen (cost analysis)
- Exhibited strategic thinking (reversibility, alternatives)
- Reduced career risk (she wasn’t just “the person who said no”)
- Created a decision-making artifact that executives could reference
For engineers aspiring to Staff+ roles, this is the pattern to internalize: when you see a significant technical decision heading in the wrong direction, your job isn’t to object—it’s to create a better-informed decision-making environment.
Sometimes that means writing a memo that changes the course of a $12M initiative. And sometimes it means saving your company from an expensive mistake nobody realized they were making.