No Kid Hungry is Share Our Strength's flagship campaign against childhood hunger, and unifying its campaign data became essential as reporting needs grew across teams. Share Our Strength's No Kid Hungry campaign ran on two disconnected systems: a MySQL database on AWS RDS holding meal, hunger, and demographic records, and a separate Salesforce org managing grant applications and reports. ASCENDING built an AWS Glue and AppFlow pipeline that unified both sources into a single, analytics-ready schema in Amazon S3, giving analysts and business users one consistent view of campaign data.
BackgroundNo Kid Hungry's Data Lake and Analytics Stack
Share Our Strength is a national nonprofit that has led the fight against childhood hunger and poverty since 1984, raising over $100 million annually across several large-scale campaigns. No Kid Hungry, its first and most influential campaign, generates broad meal, hunger, poverty, and demographic data alongside grant applications and reporting activity used by data experts on Tableau, Power BI, Amazon QuickSight, and SageMaker for dashboards, reporting, and machine learning.
That data lives behind a complex data lake architecture designed to ingest, cleanse, and aggregate information from multiple external resources before it reaches the clean zone that downstream tools consume.
The ChallengeSalesforce and MySQL Data Split Across Two Incompatible Schemas
The challenge is a governance problem as much as a technical one, since No Kid Hungry's meal, hunger, and grant data lived in systems that different teams owned independently. No Kid Hungry's operational data was split across two systems owned by two different teams, each with its own schema and its own release cadence.
- MPA MySQL DB on AWS RDS held meal, hunger, poverty, and demographic records, while Salesforce independently managed grant applications and reports.
- The two systems were managed by separate teams, creating friction for downstream analysts and business users trying to work from a single source of truth.
- ETL processing had to be compatible with both MySQL and Salesforce schemas and transform each into a unified schema based on a mapping table supplied by the customer, without sacrificing performance or accuracy.
- Salesforce organization and county records were not natively compatible with the MySQL data lake schema, and building a reliable, automatic bi-directional sync between the two was time-consuming and labor-intensive to do manually.
An AWS Data and Analytics Competency Partner
ASCENDING is a systems integration partner experienced in bridging SaaS platforms like Salesforce with relational databases such as MySQL RDS. Share Our Strength needed a platform with strong SaaS compatibility and analytical power to bridge MySQL and Salesforce without adding operational burden. As an AWS Advanced Tier Services Partner with demonstrated Data and Analytics Competency, ASCENDING brought hands-on experience from similar data consolidation engagements, and was selected as the solution provider and consulting partner to deliver the migration and integration.
The SolutionAWS Glue ETL and AppFlow Salesforce Integration Pipelines
The solution is a dual-pipeline architecture that treats schema unification and Salesforce synchronization as two separate but coordinated data flows. ASCENDING designed two complementary AWS Glue and AppFlow pipelines that together closed the gap between the MySQL and Salesforce systems.
AWS Glue ETL Pipeline: Mapping MySQL RDS Tables to a Unified Schema
For consolidating and aggregating the two data sources into a unified analytics schema:

- AWS Glue Crawlers scanned both the MySQL RDS tables and S3-based static lookup tables, registering their schemas in the AWS Glue Data Catalog.
- A Glue job read the reference/lookup tables from the catalog and applied the customer-provided mapping table to transform each source schema into one unified format.
- Amazon Athena ran ad hoc queries against the catalog for validation before the transformed output was written back to S3.
- The unified records landed in an output staging bucket in Amazon S3, ready for consumption by Tableau, Power BI, QuickSight, and SageMaker.
AWS AppFlow: Bi-Directional Salesforce and Data Lake Synchronization
For keeping Salesforce organization and county records in sync with the MySQL data lake:

- AWS AppFlow built a managed connection to Salesforce and read reference tables directly into the S3 staging layer.
- Processed output from the data lake was sent back to the corresponding Salesforce objects, completing a bi-directional flow between the two systems.
- Salesforce's schema was automatically registered with the AWS Glue Data Catalog, so a Glue Crawler could refresh the corresponding tables whenever the Salesforce schema changed.
- The client retained full control over pipeline execution schedules, running syncs on their own cadence without provisioning or managing servers.
One Unified Schema with Automated Bi-Directional Sync
The outcome is a self-sustaining data pipeline that runs unattended, freeing analysts to focus on insights instead of manual reconciliation. The combined Glue and AppFlow pipelines gave Share Our Strength one unified schema across MySQL and Salesforce, cutting the manual work previously needed to reconcile the two systems.
- Unified the output schema from Amazon RDS for MySQL and Salesforce into a single format in S3, reducing storage footprint and making downstream analytics and visualization more feasible.
- Automated a bi-directional data flow between Salesforce and MySQL RDS, transferring data at scale without provisioning system resources.
- Kept the Glue Data Catalog current automatically, so schema changes in Salesforce no longer required manual crawler or table updates.
- Gave the client full control over pipeline execution schedules to match their own operating cadence.
- Ran entirely on AWS managed services, leaving the client with zero infrastructure overhead to maintain.
Built with AWS Data Integration and ETL Services
Frequently Asked Questions
How long does it take to unify Salesforce and MySQL data with AWS Glue and AppFlow?
Timeline is a phased effort that typically starts with schema mapping and a pilot Glue job, then expands to full AppFlow synchronization once the unified output has been validated against the source systems.
How does this pipeline scale as No Kid Hungry's campaign data grows?
Scale is handled by AWS Glue and AppFlow's serverless, fully managed execution model, so processing capacity grows with data volume without the nonprofit provisioning or managing any servers.
Does keeping data in Salesforce and MySQL RDS in sync introduce security or governance risk?
Governance is preserved because each system retains ownership of its own records — Glue and AppFlow move and transform copies of the data through managed AWS services rather than granting either system direct access to the other.
What happens if Salesforce's schema changes after the pipeline is live?
Operations stay low-touch because Salesforce schema changes are automatically registered with the Glue Data Catalog, letting a Glue Crawler refresh the affected tables without manual intervention.



