.png)
Scalable Salesforce Migration on AWS
Protagona partnered with an enterprise employee experience platform to validate and build a repeatable AWS-native pipeline for migrating Salesforce data into Amazon RDS, replacing a manual, case-by-case process that couldn't scale with a growing customer base.
Industry
Startups & Software
Teams & Services
Data Architecture, Data Engineering, Engagement Management
Tech & Tools
AWS AppFlow, Amazon S3, Amazon RDS (PostgreSQL), AWS Database Migration Service (DMS), AWS Glue, Amazon VPC, AWS IAM, Terraform, CloudFormation, Jira
Key Data Points
The Vision
An AI-powered employee experience platform used by enterprises to connect, align, and engage their workforces, the company faced a data infrastructure challenge growing in direct proportion to its customer base. As that base expanded, so did the volume and complexity of customer data managed in Salesforce — data that needed to move reliably into a modern, AWS-hosted environment to support ongoing operations and analytics. Investing in a structured migration program was a deliberate strategic choice: getting this foundation right would determine how quickly and confidently the team could operate on customer data at scale. Migration tooling, in this context, was not a tactical detail but a decision with long-term architectural consequences.
The Goal
The engagement had a clear, bounded objective: validate whether AWS AppFlow could serve as the primary connector for a Salesforce-to-RDS migration, replacing an existing approach that required heavy manual intervention for each customer dataset. Success meant a working prototype pipeline, confirmed data integrity in the destination database, and a documented, repeatable architecture the internal team could carry forward and expand independently without ongoing external support.
The Challenge
The migration effort had already begun, but the existing approach was not scaling. Each customer dataset required specific, manual handling — creating bottlenecks that slowed progress and increased operational risk as record volumes grew. The core technical question was whether a single, managed AWS service could accommodate the variability across Salesforce data structures without reverting to custom, one-off solutions for each object type. Large objects and complex entity relationships added further uncertainty about where transfer bottlenecks might emerge at scale. Beyond the tooling question, the team faced architectural decisions with lasting consequences.
Choosing between AWS DMS and AWS Glue for the ETL layer required evaluating destination schema characteristics and data volume patterns specific to this environment. The solution also needed to fit within the existing AWS networking and security posture — VPC configuration, IAM access controls, and environment separation — while remaining straightforward enough for the internal team to operate independently after handoff.
The Solution
Protagona began with a structured discovery phase: a detailed review of the AWS environment and Salesforce data model, covering entity relationships, field types, and large objects likely to create transfer bottlenecks. That analysis shaped the architecture directly, ensuring every design decision was grounded in actual data characteristics rather than generic assumptions.
The core pipeline used AWS AppFlow as the extraction and ingestion layer, configured to pull Salesforce records and land them in Amazon S3. From there, the team evaluated both AWS DMS and AWS Glue for the ETL path into a PostgreSQL cluster on Amazon RDS, selecting the approach best suited to the schema and transformation requirements at hand. Network, compute, and data-layer infrastructure was provisioned using infrastructure-as-code practices with Terraform and CloudFormation, giving the organization a reproducible, version-controlled foundation for expanding the migration beyond proof-of-concept scope.
Throughout the build, the team worked alongside internal staff on data validation, confirming that records landing in RDS matched expected structure and content. At project close, all source code, architecture diagrams, and implementation documentation were delivered alongside direct knowledge transfer sessions, so the internal team could operate and extend the pipeline with confidence.
.png)
