Exams / SAP-C03 / Study guide / Replatforming, refactoring and modernization (strangler fig)
Replatforming, refactoring and modernization (strangler fig): SAP-C03 study notes and practice questions
What to know about Replatforming, refactoring and modernization (strangler fig) for the SAP-C03 exam, from the Resilience, Migration, and Business Continuity domain (15% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
SAP-C03 gives you an application with a pain point (licensing cost, scaling limits, slow releases, an aging mainframe) and a risk appetite, and asks for the modernization path that fixes the pain with acceptable effort.
Replatforming
Replatforming swaps the platform underneath with few code changes:
Density, faster deploys, no OS patching on Fargate
Cron jobs and scripts
Lambda with EventBridge Scheduler
No idle servers
Self-managed queues or brokers
Amazon MQ (same protocols) or SQS/SNS
Managed; MQ avoids code changes
Windows file servers
FSx for Windows File Server
Managed SMB with AD integration
Elastic Beanstalk is a lower-effort replatform for standard web apps.
Refactoring and the strangler fig
Strangler fig pattern: put a routing layer (API Gateway, ALB path rules, or CloudFront) in front of the monolith. Build each new capability or extracted function as a microservice, route its paths to the new service, and keep the rest going to the monolith until nothing is left. Risk stays low because each step is small and reversible.
Decompose by business capability or domain (bounded contexts), and give each service its own data store. Use events (EventBridge, SNS and SQS) instead of shared tables, and the anti-corruption layer to translate between old and new models.
Keep data in sync during transition with DMS CDC or change events from the monolith’s database.
Mainframes, .NET and databases
AWS Transform for mainframe uses agentic AI to analyze COBOL code, extract business rules, decompose applications and refactor them to Java, which helps when the knowledge of the old system is disappearing.
AWS Transform for .NET ports .NET Framework applications to cross-platform .NET so they run on Linux (and on Graviton), cutting Windows license cost.
Database modernization: DMS Schema Conversion (with generative AI assistance) or SCT converts schemas and code from commercial engines to Aurora; Babelfish for Aurora PostgreSQL lets SQL Server applications keep using T-SQL with fewer changes.
Purpose-built databases replace one-size-fits-all: DynamoDB for key-value at scale, ElastiCache for sessions, OpenSearch for search, Neptune for graphs.
How to choose
Scenario wording
Pick
“Replace the monolith gradually without a big-bang rewrite”
Strangler fig with API Gateway or ALB routing
“Remove Oracle licensing”
Convert to Aurora PostgreSQL with DMS Schema Conversion, migrate with DMS
“SQL Server app, drop SQL Server licenses with minimal code change”
Babelfish for Aurora PostgreSQL
“COBOL experts retiring, move to Java”
AWS Transform for mainframe
“.NET Framework on Windows, cut license cost”
AWS Transform for .NET, run on Linux containers
“Keep JMS/AMQP apps working on a managed broker”
Amazon MQ
Common traps
Big-bang rewrites when the scenario stresses low risk.
Shared database between new microservices and the monolith forever.
Refactoring when the business only needs to leave a data center fast.
SQS where existing apps need JMS or AMQP without code changes.
Moving a commercial database to RDS with the same engine and calling it a license saving.
A retailer's order-management application is a monolith on servers in its data center. Its web front end calls the monolith's order, returns and gift-card paths, and each path has a different owner and release schedule.
The retailer wants to move each path to a new microservice on containers, one path at a time, while the monolith keeps serving the paths not yet moved. Customers must see one consistent API throughout, and a path must be switched back quickly if the new service misbehaves.
Which approach meets these requirements?
Choose one answer.
AA. Rewrite the whole monolith as microservices on containers, and switch all customers to the new system in one planned cutover after the testing is complete.
BB. Lift the monolith as it is onto Amazon EC2 instances in AWS, and keep the code unchanged until the whole application can be rewritten later in a single project.
CC. Put an Application Load Balancer or API Gateway in front of both systems, route each path to its new microservice when it is ready, and switch a path back by changing its route.
DD. Send every request to both the monolith and the new microservices, and have the front end compare the two responses, so that each new service is proven before any customer traffic moves to it.
Show the answer and explanation
Answer: C
A. Wrong: A single cutover of a full rewrite gives no staged path and no quick way to return one path to the monolith. It also puts every path at risk on the same day.
B. Wrong: A lift-and-shift keeps the monolith as one unit, so the paths cannot move independently to containers. The option is a rehost, not the staged modernization the retailer wants.
C. Right: Correct. This strangler fig pattern moves one path at a time behind a single API, and reverting a path is a routing change. Customers see one consistent endpoint throughout.
D. Wrong: Duplicate writes to both systems can record each order twice or diverge the data, and the comparison does not switch any path over. The approach does not provide a clean staged move.
Explanation
A routing layer in front of both systems moves one path at a time and lets the team switch a path back by changing its route, which matches the strangler fig pattern. A full rewrite cutover, a lift-and-shift and dual writes each fail the staged move or the rollback requirement.
Want more on Replatforming, refactoring and modernization (strangler fig)? The 5 full-length practice sets have 7 more Replatforming, refactoring and modernization (strangler fig) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Replatforming, refactoring and modernization (strangler fig)