The challenge
Our client's Performance & Talent platform is an API-first product. For clients with modern integration capabilities, that's a strength: structured, authenticated, documented API calls to push data in and pull data out. Clean, predictable, automatable.
But enterprise client bases are rarely uniform. For a significant number of the platform's customers, particularly in sectors with older IT infrastructure or limited in-house technical resource, "API-driven" meant "we can't use it." Their existing HR and payroll systems exported flat files. Their IT teams knew how to schedule an SFTP transfer. They did not have developers who could write API integrations, and they were not going to acquire them.
The gap was clear: our client had a capable platform that customers couldn't connect to in the way they were able to work. The choice was between asking clients to invest in technical capability they didn't have, or building a bridge.
The solution
We designed and built 2 lightweight adapter applications — 1 for SFTP, 1 for FTPS — that sit as thin layers in front of the platform's API.
The model is deliberately simple. A client drops a file onto their allocated directory using the file transfer protocol their own systems already support. The adapter picks it up, validates it, transforms it into the format the API expects, and makes the upstream API call on the client's behalf. To the client, the integration looks like an ordinary file transfer — the kind their systems have been doing for decades. To the platform, it looks like a standard API call.
Keeping the adapters thin was a deliberate architectural decision. The goal was not to build a general-purpose ETL layer or add business logic that would drift out of sync with the platform. Each adapter's job is narrow: accept a file over a secure channel, parse it, make the API call, handle the response, and log the result. The application logic stays in the platform where it belongs. The adapters are purely about closing the protocol gap.
Both applications handle authentication, per-client directory isolation, error handling with meaningful status reporting, and logging sufficient for support and audit purposes. FTPS support covers both explicit and implicit TLS modes to accommodate the range of client-side transfer tools in use across the customer base.
The infrastructure
The adapters were originally deployed as Docker containers running on EC2 instances. This worked, but it carried operational overhead — instance management, patching, capacity planning — that was disproportionate to the nature of the workload. File transfer adapters are not continuously busy; they respond to file arrival events and are otherwise idle. Paying for and managing persistent EC2 capacity for that kind of workload is the wrong shape of infrastructure.
We migrated both applications to ECS Fargate. Under Fargate, the containers run on AWS-managed compute without the need to provision or maintain the underlying EC2 instances. The applications run exactly the same container images; only the hosting layer changed. The result is a simpler operational model, better cost efficiency for the actual usage pattern, and the same availability and resilience characteristics — Fargate tasks run within the same VPC and networking configuration, and are monitored and restarted automatically on failure.
The migration also gave us the opportunity to tighten the deployment pipeline, which led directly to the second significant piece of work.
Handing over deployment control
While Elysium managed the initial development and infrastructure, the longer-term goal was for the client's own engineering team to own the applications and deploy changes independently. Dependency on an external team for deployments adds friction, slows down iteration, and creates a bottleneck that doesn't serve either party well.
We built a GitHub Actions CI/CD pipeline to solve this. The pipeline builds and tests the container images on pull request, then on merge to the main branch, builds the release image, pushes it to Amazon ECR, and triggers a Fargate task definition update to roll out the new version. The client's engineers can now deploy changes to either adapter by merging a pull request — the same workflow they use for the rest of their codebase.
The pipeline handles environment promotion, image tagging, and the ECS service update in a single automated flow. There is no manual step between code review and production deployment; the process is auditable through the GitHub Actions run history, and rollback is a matter of redeploying a previous image tag.
The outcome
The SFTP and FTPS adapters are now live and in use across a range of the platform's customers who previously had no viable path to integration. Clients that export flat files from their HR systems connect through the adapters without any change to their existing processes. Data reaches the platform reliably and on schedule.
The infrastructure migration to ECS Fargate removed the operational overhead of EC2 instance management without any disruption to the running applications. The hosting model is now correctly sized for the workload.
The GitHub Actions deployment pipeline has transferred day-to-day ownership of the applications to the client's team. They can iterate, fix, and ship changes on their own schedule. The engagement has moved from ongoing dependency to a clean handover — which is exactly where it should be.