Wordworks is a fast-growing B2B MarTech SaaS platform that provides marketing automation, campaign orchestration, and real-time analytics to roughly 400 mid-market organizations. The platform handles highly spiky workloads, serving about 150,000 active users and processing millions of webhooks during peak campaign hours.
Their legacy infrastructure, hosted on a secondary cloud provider (Virtual Machines) and a legacy colocation facility, was cracking under the pressure of these traffic spikes. Because they lacked dynamic scaling, the engineering team had to manually overprovision servers before major client campaigns. Customer onboarding took nearly a week due to heavy manual database configuration.
Leveraging the AWS Migration Acceleration Program (MAP), we executed a highly compressed, 16-week modernization sprint. We moved Wordworks from a rigid, VM-based architecture to a decoupled, multi-tenant environment using serverless containers (AWS Fargate) and managed messaging queues.
Key Outcomes:
· 45% reduction in compute costs by eliminating idle VMs.
· Server provisioning time cut from 5 days to 30 minutes.
· Zero-downtime scaling during massive marketing campaign spikes.
· Accelerated modernization delivered end-to-end in just 16 weeks.
· Attained SOC 2 compliance readiness via native AWS security controls.
Attribute | Details |
Industry | SaaS (Marketing Technology & Automation) |
Products | Campaign Builder, Real-time Analytics Dashboard, Webhook Engine |
Customers | ~400 mid-market organizations |
Active Users | ~150,000 |
Deployment Model | Hybrid Single/Multi-tenant (Siloed databases) |
Regions | North America |
Employees | ~110 (45 engineering) |
Prior Infrastructure | Secondary Cloud VMs + Regional Colocation |
Migration Timeline | 16 Weeks Total |
Wordworks had just closed a Series B funding round and needed to scale aggressively. However, their infrastructure was a massive liability. Every time a client launched a large email or SMS campaign, the resulting webhook traffic would cause database deadlocks and crash the reporting dashboards for other tenants.
Strategic Objectives:
· Decouple the monolithic architecture to handle spiky, unpredictable traffic.
· Migrate off legacy VMs and adopt a low-maintenance, serverless compute model.
· Consolidate siloed tenant databases into a scalable multi-tenant datastore.
· Complete the migration within a strict 4-month window before the Q4 holiday marketing rush.
· Establish a security posture capable of passing a SOC 2 audit.
Marketing campaigns are inherently spiky. When a major client blasted a campaign, the platform would get hit with tens of thousands of requests per second. Because the ingestion engine and the web application shared the same monolithic VM cluster, these spikes would starve the application of resources. Dashboards would freeze, affecting every other customer on the platform.
While the application tier was somewhat shared, the database tier was siloed. Every new customer required a DBA to manually spin up and configure a new MySQL instance in the colocation facility. This pushed tenant onboarding out to 5–7 days, frustrating new clients and delaying revenue recognition.
To prevent crashes during spikes, Wordworks ran their VMs at 80% overcapacity 24/7. They were paying for peak-load compute even on Sunday nights when traffic was virtually zero. This burned through cash that should have been allocated to product development.
Enterprise clients were starting to demand SOC 2 compliance, but the legacy colocation facility lacked basic audit trails, centralized logging, and strict IAM controls. The sales team was actively losing enterprise deals because the infrastructure couldn't pass security questionnaires.
Given the aggressive 16-week timeline, we couldn't afford a multi-year Kubernetes re-architecture. We needed high-impact, low-overhead managed services.
Principle 1 — Serverless Containers for Speed and Scale
Instead of building and managing an Amazon EKS cluster, we pivoted the application to Amazon ECS with AWS Fargate. This allowed us to containerize their monolithic app into distinct services (Ingestion, Core App, Analytics) without the team having to manage underlying EC2 instances. It delivered the auto-scaling they desperately needed with zero cluster maintenance.
Principle 2 — Decoupling via Event-Driven Architecture
To solve the "noisy neighbor" webhooks crashing the system, we introduced Amazon SQS and Amazon SNS. Webhook traffic is now immediately dumped into an SQS queue. The ingestion service pulls from this queue at its own pace. If a traffic spike hits, the queue simply buffers the load, completely protecting the core web app from going down.
Principle 3 — Unified Multi-Tenant Database Strategy
We migrated their scattered, siloed MySQL instances into a unified Amazon Aurora MySQL cluster. We redesigned the schema to enforce logical tenant isolation at the row level. This allowed us to pool database resources, dramatically lowering costs and reducing onboarding time to minutes.
Principle 4 — Automated Compliance Posture
We established an AWS Landing Zone utilizing AWS Control Tower and Security Hub. By enforcing encryption at rest (KMS) and enabling CloudTrail logging out-of-the-box, we immediately unblocked their SOC 2 compliance efforts.
We aggressively targeted replatforming to hit the 16-week deadline.
Strategy | No. of Workloads | Applications / Components | Rationale |
Replatform | 18 | Web application, background workers, databases. | Containerized the VMs to run on ECS Fargate; migrated self-hosted MySQL to Aurora MySQL. |
Refactor | 4 | Webhook ingestion layer. | Stripped this out of the monolith and wired it to Amazon SQS/SNS to handle peak load buffering. |
Rehost | 3 | Legacy SFTP servers, internal BI tools. | Lift-and-shifted directly to EC2 to save time, as they were low-priority and didn't need immediate modernization. |
Retire | 5 | Legacy load balancers, duplicate staging VMs. | Replaced entirely by AWS ALBs and dynamic Fargate staging environments. |
· Amazon ECS with AWS Fargate: The compute backbone. Chosen because the engineering team lacked Kubernetes expertise and needed a fast path to auto-scaling containers without managing servers.
· Amazon Aurora MySQL: Replaced dozens of fragmented databases. Handled the heavy read/write loads of marketing analytics with built-in fault tolerance.
· Amazon SQS & SNS: The shock absorbers. Decoupled the data ingestion layer from the application layer to prevent system crashes during traffic spikes.
· Application Load Balancer (ALB): Handled advanced routing between the new containerized microservices.
· AWS Control Tower: Used to instantly deploy a secure, multi-account Landing Zone to accelerate SOC 2 compliance.
· Amazon EKS (Kubernetes): Rejected. While powerful, the learning curve and cluster management overhead would have derailed the strict 16-week timeline. Fargate was the faster, leaner choice.
· Lift-and-Shift (Pure Rehost): Rejected. Simply moving their VMs to EC2 would not have solved the webhook bottleneck or the noisy neighbor crashes.
The target state is a decoupled, containerized SaaS platform deployed across two Availability Zones within the us-west-2 region.
Attribute | Implementation Details |
Deployment Model | Multi-tenant SaaS (Logically isolated) |
Compute Strategy | Serverless containers (No EC2 management) |
Availability | Multi-AZ for App and Data layers |
Scalability | CPU/Memory-based auto-scaling via ECS |
Buffering Layer | SQS message queues for heavy I/O |
Public Layer: AWS WAF (Perimeter security), ALB (Traffic distribution). Application Layer: Amazon ECS on Fargate (Core App & Worker containers), Amazon SQS (Webhook buffering), Amazon SNS (Pub/Sub notifications). Data Layer: Amazon Aurora MySQL (Multi-tenant transactions), Amazon ElastiCache for Memcached (Query caching), Amazon S3 (Asset storage). Security & Gov: AWS Control Tower (Account baseline), KMS (Encryption), IAM. Observability: Amazon CloudWatch (Container insights, alarms).
When a massive email blast triggers millions of user clicks:
1. Traffic hits the ALB and is routed to a lightweight Ingestion Container (ECS Fargate).
2. The container immediately drops the payload into an Amazon SQS Queue and returns a 200 OK to the user in milliseconds.
3. Background Worker Containers process the queue at a steady, controlled rate, writing to Aurora MySQL without overwhelming the database locks.
We compressed the MAP phases by leaning heavily into AWS managed services and automated migration tooling.
Phase | Duration | Key Activities & Deliverables |
Phase 1: Assess & Mobilize | Weeks 1–4 | Rapid discovery, Landing Zone deployment via Control Tower, Dockerizing the legacy monolithic codebase, and setting up GitHub Actions for CI/CD. |
Phase 2: Migrate (Wave 1 - Data) | Weeks 5–8 | Consolidated the fragmented MySQL databases into Aurora using AWS Database Migration Service (DMS). Validated schema multi-tenancy. |
Phase 3: Migrate (Wave 2 - App) | Weeks 9–13 | Deployed the ECS Fargate clusters. Refactored the webhook ingestion to route through SQS. Conducted heavy load-testing against the queue architecture. |
Phase 4: Cutover & Optimize | Weeks 14–16 | Executed a DNS cutover. Rightsized Fargate task CPU/Memory allocations based on live CloudWatch metrics. |
We used a phased DNS cutover via Route 53. First, we migrated the asynchronous background workers (which had no user-facing impact). Once stable, we used AWS DMS to keep the legacy DB and Aurora in sync. Finally, we flipped the DNS for the main web application during a scheduled 2-hour low-traffic window on a Saturday night. The actual cutover took just 15 minutes.
Metric | Before (Legacy VMs) | After (AWS Native SaaS) | Impact |
Compute Cost | High (Paying for idle capacity) | 45% Lower | Fargate scales down to zero during off-hours. |
Onboarding Time | 5–7 Days | < 30 Minutes | Fully automated multi-tenant provisioning. |
Uptime during Spikes | Frequent dashboard freezes | 100% Uptime | SQS completely decoupled the load. |
Deployment Time | Manual (Hours) | Automated (Minutes) | CI/CD pipeline integrated directly with ECS. |
Migration Velocity | N/A | 16 Weeks | Extremely rapid time-to-value for the client. |
Elimination of the "Noisy Neighbor"
By implementing the SQS buffering layer, we solved Wordworks's biggest existential threat. One client's massive marketing blast no longer degrades the platform for everyone else. The system just absorbs the spike and processes it calmly in the background.
Lean Engineering Focus
By moving to AWS Fargate and Aurora, Wordworks’s engineers no longer patch OS kernels, manage database failovers, or worry about disk space. They have transitioned from infrastructure operators back to software developers.
Unblocking Enterprise Sales (SOC 2)
The move to a secure AWS Landing Zone allowed Wordworks to check all the necessary boxes for their upcoming SOC 2 audit. Features like automated key rotation, VPC flow logs, and centralized CloudTrail tracking instantly cleared the compliance hurdles that were previously stalling enterprise deals.
The Wordworks migration perfectly illustrates how the AWS Migration Acceleration Program (MAP) can be leveraged for high-velocity SaaS modernization. By consciously avoiding overly complex orchestration tools and leaning into purpose-built managed services like ECS Fargate and Amazon SQS, we delivered a massive architectural shift in just 16 weeks.
The transformation moved the customer from a fragile, manually scaled VM environment to an elastic, event-driven SaaS architecture. Financially, it traded heavy, continuous compute waste for a highly optimized, consumption-based model. Operationally, it eliminated the database bottlenecks that were stalling customer onboarding and causing system outages during peak marketing loads.