Architecting Large-Scale Migrations with Fannie Mae and the NRO (AWS re:Invent 2025 – WPS201)
Source: Dev.to
Why large migrations are hard
The session opens by revisiting familiar migration drivers: lowering compute costs and increasing innovation velocity as organizations move from on‑premises environments to rehosted, replatformed, and cloud‑native architectures.
The speaker frames migration strategy in terms of the “7 Rs,” emphasizing that large‑scale programs almost always use a mix of these approaches rather than a single pattern.
Strategy
| Strategy | Description | Best For |
|---|---|---|
| Rehost | “Lift and shift” to cloud | Quick migration, minimal changes |
| Relocate | Move to different infrastructure | Hypervisor‑level migrations |
| Repurchase | Move to SaaS solutions | Replacing custom applications |
| Retain | Keep on‑premises | Compliance or latency requirements |
| Retire | Eliminate unused applications | Reducing technical debt |
| Replatform | Minor cloud optimizations | Moderate benefits with low risk |
| Refactor | Redesign for cloud‑native | Maximum cloud benefits |
Key Message: Tooling alone is not enough, especially when dealing with diverse legacy systems, complex databases, and tight budgets. Organizations with limited cloud experience must invest early in automation, governance, and repeatable mechanisms for account management.
The session recommends using an AWS Migration Readiness Assessment (MRA) as an on‑ramp for any large program. The MRA process helps:
- Inventory applications and discover dependencies
- Determine appropriate migration strategies per workload
- Avoid one‑off, unstructured decisions
Migration Assessment Phases
| Phase | Focus | Key AWS Tools |
|---|---|---|
| Assess | Discovery & planning | Application Discovery Service, Migration Readiness Assessment |
| Mobilize | Setup & preparation | Control Tower, Landing Zone, Account vending |
| Migrate/Modernize | Execution & optimization | Migration tools, Well‑Architected reviews |
In parallel, organizations should establish an AWS Control Tower‑style landing zone or “account vending machine” to provision new accounts quickly and consistently, with built‑in guardrails for security, compliance, and governance.
AWS Well‑Architected Framework
The framework serves as the backbone for design and review. The six pillars are positioned as a way to reason about trade‑offs for each workload, not as a checklist to satisfy after migration.
| Pillar | Focus Area | Key Considerations |
|---|---|---|
| Operational Excellence | Running & monitoring systems | Automation, procedures, continuous improvement |
| Security | Protecting information & systems | Identity, permissions, data protection |
| Reliability | System availability & recovery | Fault tolerance, backup, disaster recovery |
| Performance Efficiency | Using resources effectively | Right‑sizing, monitoring, technology selection |
| Cost Optimization | Delivering value at lowest cost | Resource optimization, pricing models |
| Sustainability | Minimizing environmental impact | Efficiency improvements, renewable energy |
Practical Tip: Ask business stakeholders which pillars matter most for each application. Some workloads may emphasize reliability and operational excellence, while others prioritize cost or performance. These decisions should drive architecture choices, capacity planning, and operational runbooks.
Cloud Center of Excellence (CCoE)
A cross‑functional team spanning:
- ☁️ Cloud architecture
- 🖥️ Infrastructure
- 🔒 Security
- ⚙️ Operations
- 💻 Software engineering
CCoE Responsibilities
- ✅ Standardizing landing zones and network patterns
- 🔐 Defining IAM controls and security policies
- 💰 Establishing cost‑management practices
- 📚 Codifying best practices and lessons learned
- 🚀 Enabling innovation across business units
Both Fannie Mae and the NRO leveraged CCoEs to significantly increase their “innovation velocity” after completing initial migrations.
Fannie Mae Forecast Transformation
Business Context
- Purchases home loans from lenders
- Packages them into mortgage‑backed securities
- Sells securities to investors
Accurate, timely forecasting of portfolio performance is mission‑critical.
Challenges
| Challenge | Impact |
|---|---|
| Spreadsheet‑heavy processes | Manual errors, limited scalability |
| Fragmented systems | Data silos, integration complexity |
| End‑of‑life infrastructure | Performance bottlenecks, maintenance costs |
| Spread‑thin expertise | Knowledge silos, single points of failure |
| Heavy customizations | Slow change cycles, brittle systems |
Program Goals (Forecast Transformation Program – launched Sep 2023)
| Metric | Before | Target | Improvement |
|---|---|---|---|
| Forecasting lifecycle | ~80 days | ~10 days | 87.5 % reduction |
| Stress‑test execution | Sequential | Parallel | Concurrent processing |
| System consolidation | ~80 systems | 1 platform | 98.75 % reduction |
| Calculations consolidated | ~2,000 | Unified | Single source of truth |
| Loan records capacity | Limited | 1.5 B per run | Massive scale |
Key attributes of the solution:
- ⚡ Auto‑scaling compute based on demand
- 🔒 Strict regulatory compliance (security, auditability, data quality)
- 🎭 Holistic approach – tackling people, process, technology, and governance simultaneously
Architecture Overview
| Component | AWS Service | Purpose | Key Benefits |
|---|---|---|---|
| Data Backbone | Amazon S3 | Unified data domain | Stores input data, model outputs, calculation results, analytics data |
| Compute Engine | Amazon EMR | Big data processing | Handles billions of loan records across multiple clusters; auto‑scales |
| Orchestration | AWS Step Functions | End‑to‑end workflow | Coordinates data ingestion, models, calculations, system integration |
| Metadata & Config | Aurora + DynamoDB | Configuration management | Stores scenarios, model parameters, calculation rules |
| User Interface | Angular on AWS Fargate | Business user experience | Enables scenario definition, input specification, execution triggers |
| Analytics | Amazon SageMaker + Tableau | Reporting & analysis | Supports regulatory reporting and internal analytics |
Business Rules in YAML
A clever design encodes business calculations in YAML, which:
- ✅ Decouples business logic from application code
- ✅ Enables business‑driven changes without code redeployment
- ✅ Reduces development cycle time for rule updates
graph TD
A[Business User Input] --> B[Data Ingestion]
B --> C[S3 Data Backbone]
C --> D[Model Execution]
D --> E[EMR Calculations]
E --> F[Output Processing]
F --> G[Analytics & Reporting]
Workflow steps
- User Input: Business users select scenario types and enter assumptions via UI.
- Data Ingestion: Platform pulls data from multiple systems of record.
- Data Storage: All data written to the S3 data backbone.
- Model Execution: Invokes existing and new platform‑specific models.
- Rule Application: EMR applies thousands of YAML‑defined business rules.
- Output Distribution: Results routed to downstream systems via APIs and SNS.
- Analytics Preparation: Data prepared for regulatory and management tools.
Implementation Challenges
| Challenge | Scale | Solution Approach |
|---|---|---|
| Team coordination | 100+ engineers | Standardized guardrails, coding standards, integration patterns |
| System integration | 76 upstream/downstream systems | Careful API design, minimal disruption approach |
| Program duration | Multi‑year timeline | Consistent governance, incremental delivery, automated testing |
The session highlighted that combining proven migration patterns, a strong governance framework, and a dedicated Cloud Center of Excellence enables organizations like Fannie Mae and the NRO to execute large‑scale migrations while maintaining security, compliance, and operational excellence.