Case study
Enterprise Recruiting Platform
How we integrated an acquired recruiting system into a Salesforce-based platform, ran old and new side by side across Azure and AWS with no customer downtime, and grew with the client from zero to 30+ enterprise customers.
Three recruiting products, two clouds, one platform underneath
Sector Enterprise recruiting software · Market Germany · Duration ~4 years · Role Architecture, integration & implementation, DevOps, customer data migration
The challenge
A German recruiting startup had built its platform on Salesforce: Salesforce as the recruiting CRM and system of record, plus a client-facing web app where recruiters present candidates to their clients. It then bought an established recruiting system with a large live customer base - a system our team already maintained and developed for its previous owner. What the startup was really acquiring was that system's core know-how: a proven method for personality and competency assessment of candidates.
The plan was to bring the two together. The constraints made that hard. The acquired system's customers used it every day. It ran on Azure; the startup's platform ran on AWS. And there could be no cutover weekend, no migration window, no day on which a customer was told to stop working.
So for a long stretch, everything ran in parallel. The acquired system was rebuilt as a new product on AWS while the original stayed live on Azure - and we kept maintaining both. The startup's own products kept moving forward alongside them. Three products, three teams, and every new feature implemented separately in each: multiple codebases, multiple databases, two clouds.
Old and new, live at the same time
We designed the integration so customers never had to pick a date. The original system and its AWS successor both stayed live with their data kept in sync, and each customer could move to the new platform whenever they were ready - using both in the meantime.
The mechanism was asynchronous events plus batch synchronisation. Changes in the original system were published through Azure Service Bus and consumed on the AWS side, and a dedicated connector service ran batch syncs of the data from Azure to AWS. Underneath sat the heavy part: data moving between CouchDB, MongoDB and PostgreSQL, and years of platform's files - documents, attachments, images - moving from Azure Storage into S3.
Switching platforms became a customer decision rather than a project. No downtime, no freeze, no migration period.
Build once, use everywhere
Running three products in parallel made the cost of duplication impossible to ignore. We attacked it on two fronts.
Connectors around Salesforce. Salesforce stayed the system of record. We built connector services that keep it in sync with every other part of the platform - asynchronous events for changes as they happen, batch syncs for bulk data - so no product needs its own hand-built integration with it. On AWS the services talk through EventBridge, SNS and SQS, so products react to each other's events without being coupled to each other's code.
Shared UI as web components. We introduced a micro-frontend layer: UI components, logic included, built once as web components and embedded in every product that needs them. A feature built once becomes available across the products without being rebuilt - which is what finally broke the "every feature three times" pattern.
Onboarding customers from legacy systems
The startup's growth came from enterprise customers who already had recruiting systems of their own, holding years of candidate, vacancy and client data. Every new customer meant a migration into Salesforce.
Part of our team was dedicated to that work full-time and owned it end to end. They worked directly with the startup's onboarding managers and with the customers themselves: evaluating the legacy data structures, agreeing with each customer how they map onto the platform, migrating large volumes of historical data, and supporting the go-live switch. After go-live they stayed on, answering the customer's requests and keeping things running.
Migration quality decides whether a new enterprise customer trusts a platform in its first month. Owning the whole process - rather than handing over once the data has landed is what made onboarding repeatable as the customer count climbed.
Startup speed, enterprise standards
A startup needs to ship fast on a tight budget; enterprise customers expect quality, performance and security regardless. We closed that gap by automating nearly everything between writing code and running it in production.
Infrastructure, CI/CD pipelines and all DevOps work sat with our team throughout. Every service runs on AWS ECS and is delivered through GitHub Actions and AWS CodePipeline. Unit, integration and end-to-end tests gate every change, so shipping often doesn't mean shipping risk.
Senior direction for a young team
The startup's in-house developers were early in their careers. Alongside delivery, we brought the experience: consultation, engineering guidelines and direction on how the platform should evolve.
We made the architecture calls - weighing scalability, availability, performance and security against the cost of infrastructure and of operating a complex system across two cloud providers. On a startup budget every one of those is a trade-off, and someone has to own it.
Result
Over roughly four years the business grew from zero to 30+ enterprise customers on the platform. Customers of the acquired system moved across on their own schedule with no downtime, and each new customer arrived from its legacy system with its history intact.
Stack Salesforce · Node.js (Express, NestJS) · Vue.js · web components / micro-frontends · AWS ECS · EventBridge · SNS / SQS · Azure Service Bus · PostgreSQL · MongoDB · CouchDB · Azure Storage → S3 · GitHub Actions · AWS CodePipeline
Client name and reference available on request under NDA.