How Atlas Copco CTS cut €1M in annual costs by consolidating three legacy data platforms
Migrating three legacy data platforms to Databricks before the license deadline
Atlas Copco
Atlas Copco is a global industrial group organized into four business areas. The largest, Compressor Technique, is where the company designs and sells its compressors. Inside it, Compressor Technique Services is the leading team for data initiatives: it runs the Databricks platform, the "Intelligence Hub," and serves data to other departments across the business area, from operations to sales and marketing. Before we arrived, that team was carrying three platforms at once. Two SAS servers and a TIBCO layer held years of ETL logic and business rules. TIBCO is a data virtualization tool, but here it had become a de-facto data platform, with transformations stacked up in a layer never designed to hold them. Both were slow to develop on and near the end of their life. Alongside them sat Databricks, where the team wanted to be. Running all three meant paying for all three. The operations data and analytics team felt it most. They had the heaviest dependencies on SAS, which meant they could not develop much new while the old platform stayed in place. The trigger was concrete: the SAS and TIBCO licenses expired in the first quarter of 2026. Everything had to move before then. The scope was not small. Around 25 jobs, roughly 170,000 lines of SQL, with single jobs ranging from one file to a 70-file dependency chain of 10,000 lines.
This was a blended team, not a handoff. Atlas Copco held the business knowledge and the big-picture overview; we owned the technical implementation. We worked through daily standups and a weekly migration sync, and we ran the migration iteratively: scope a job, migrate it, get the dashboard owner to sign off, then sit down with their engineers for a two-hour session on the dbt or Python code and the CI/CD setup, and stay available for questions after. We ran several jobs in parallel so onboarding and migration moved together rather than one after the other. The client's engineers came out able to do things they could not before. They picked up dbt and liked how simple it was, enough to plan to keep using it. They learned the CI/CD and asset-bundle practices that now sit in every migrated pipeline. Not everything was smooth, and the honest bumps are worth naming. dbt and Databricks do not always sit well together, and some features we needed depended on the platform team's availability. We discovered orphaned datasets with no clear owner that held up a handful of jobs. And we learned we should have aligned earlier with teams outside Compressor Technique Services, some of whom expected their dashboards to look identical when upstream sources they owned had not moved the same way. Next time we would set those expectations sooner.
We started with analysis, not code. The first two months went into mapping dependencies across the three platforms. The Compressor Technique Services team had already done solid groundwork, and we took it further at the code level, where dependencies hide that no diagram shows. That upfront work is what let us cut the migration down job by job instead of being surprised by it later. For the migration itself we chose dbt. It is SQL-first and modular, which fit the shape of the legacy logic and made it easy for the client's own engineers to read and own afterwards. We built every migrated job on minimal best practices from the start: CI/CD and Databricks Asset Bundles in each one. We also packaged a dbt template on the Intelligence Hub with CI/CD and asset bundles pre-configured, so a new migration could start from a working baseline. That template stays behind as a reusable asset for the team's future work. Where a job had a clear use case and limited blast radius, we reshaped it as a data product, source-aligned and consumer-aligned, with explicit ownership and a governance model that fits the Databricks setup. We migrated seven to eight data products this way. They became the working examples the team needed to see how data product thinking holds up in practice.
The updated content strategy improved clarity and engagement across the website. Users now understand what Vireonix offers much faster, resulting in stronger trust, better flow, and a more confident brand presence.