When organizations modernize their data and analytics environments, the conversation can quickly become framed as a choice: keep the established platform or replace it with something new.
But that framing can obscure the questions that matter most. Which workloads are supporting critical business decisions? What intellectual property has been built into them? How will a change affect users, governance and regulatory obligations? And what will it actually cost to reproduce the same outcomes on another platform?
A large financial services organization recently faced these questions as it evaluated whether to expand its use of Databricks and migrate analytical workloads from SAS. What began as a platform standardization discussion became a much more comprehensive examination of workload economics, productivity, migration risk and business value. Ultimately, the organization determined that SAS and Databricks could coexist, with each platform supporting different needs across its data and analytics environment.
I spoke with SAS experts involved in the evaluation to understand what other organizations can learn from the experience.
What prompted the organization to consider moving SAS workloads to Databricks?
SAS expert: Databricks already had a small presence in the organization and there was momentum within IT to expand its use as a corporate standard. The question was whether they could migrate the analytics workloads running in SAS to Databricks, including users.
But the organization had critical analytical processes and business knowledge supporting areas such as risk management, forecasting and eligibility determination – all of which relied on SAS. These were not isolated programs that could simply be copied from one environment to another.
That changed the nature of the question. The decision was no longer just, “Which platform should we standardize on?” It became, “What would it take to reproduce the work, controls and business outcomes we already depend on?”
How did the organization make the comparison more objective?
SAS expert: The first step was to replace assumptions with evidence.
SAS used ecosystem diagnostics to examine the existing environment, including the procedures being executed, workload patterns, runtimes and resource consumption. That analysis provided a much clearer picture of how people were actually using SAS and how much analytical work the environment was supporting.
The team then mapped those workload profiles to a projected Databricks environment. Different types of work were associated with the likely machine sizes, nodes and operating hours they would require. Publicly available Databricks cost information was used to estimate the corresponding consumption costs.
This was important because the evaluation did not rest on a generic claim that one platform was always less expensive than another. It examined their workloads and asked what it would cost to perform comparable work in a different environment.
That fact-based approach helped shift the discussion from platform preference to business impact.
What cost factors were most important?
SAS expert: Infrastructure consumption was only one part of the total cost.
The team considered the compute resources and runtime needed to support existing workloads, as well as the effort required to move them. Much of the organization’s SAS code had been refined over many years. Re-creating it elsewhere would require teams to identify appropriate alternatives, rewrite processes, test the results and tune each workload for a new execution environment.
That work has a cost. So does the potential disruption to employees.
Many users had established workflows that included low-code, visual processes. Moving those workflows to a more code-driven environment could require new programming skills and change how they perform their daily work. The original cost projection assumed that their productivity would remain the same, even though the analysis suggested that some users could require more time to complete comparable tasks. In a consumption-based model, additional time and less efficient code could also increase platform costs.
For a regulated organization, validation introduced another consideration. Rebuilt analytical processes could not simply be assumed to produce equivalent results. They would need to be tested, compared and, where appropriate, operated in parallel until the organization could demonstrate that the new implementation was producing the required outcomes.
A credible total cost of ownership analysis, therefore, needed to account for more than a license or consumption rate. It had to include:
- Infrastructure and compute consumption.
- Workload conversion and re-engineering.
- Testing and validation.
- User training and productivity.
- Parallel operations during transition.
- Ongoing workload optimization.
- Governance and operational support.
What did the analysis reveal?
SAS expert: For the workloads evaluated in this regulated financial services company, hosted SAS Viya was estimated to be 35% to 52% less expensive than the projected Databricks alternative.
The percentage is compelling, but the methodology is the more important part of the story.
The exercise revealed the risks of relying on an abstract promise of lower cost without first understanding current consumption, future workloads or the resources needed to re-engineer established analytics. A consumption-based platform may appear flexible, but organizations still need to understand what they will consume and how efficiently their workloads will operate.
Why did user productivity matter so much?
SAS expert: Analytics modernization is not only a technical architecture decision. It changes how people work.
The existing environment allowed users to move between data preparation and analytical procedures within familiar workflows. Separating those activities across tools could interrupt that flow and introduce more handoffs.
There was also a large body of established SAS intellectual property to consider. This included code, analytical logic, process knowledge and workflows built around the business's needs. Preserving those assets represented continuity. Rebuilding them introduced cost and uncertainty.
Why were governance and financial services capabilities critical?
SAS expert: In financial services, a model is not complete when it produces a result. The organization must be able to understand how the model was developed, how it was validated, where it is deployed, how it is monitored and whether it continues to perform as expected.
That made model governance, auditability, regulatory compliance and model risk management central to the evaluation. The organization needed to identify its mission-critical workloads and understand how their controls would be preserved through any transition.
SAS also provided capabilities beyond an underlying data platform, including analytics, forecasting, optimization, governance, decisioning and support for business-user productivity. The recommended architecture, therefore, did not require the organization to reject Databricks. Instead, it recognized that the two platforms could play different roles. Databricks could support data engineering and lakehouse requirements, while SAS could continue supporting governed analytics and business decisioning.
The outcome was coexistence, not a simplistic winner-takes-all decision.
Did the organization stop using Databricks?
SAS expert: No. Databricks remains part of the technology environment.
The evaluation showed that deciding where to store and engineer data is not necessarily the same as deciding where every analytical workload should run.
By separating those questions, the organization could apply each platform where it delivered appropriate value for the cost. This also allowed the company to modernize without discarding validated analytical assets or forcing unnecessary disruption across the business.
What can other organizations learn from this experience?
SAS expert: Start by understanding what you have before deciding what to replace.
Inventory the workloads. Identify which ones are mission-critical. Measure actual runtime and consumption. Understand who uses the environment and how they work. Determine which models, processes and decisions are subject to governance or regulatory controls.
Then evaluate the full cost of change. Include re-engineering, training, validation, parallel operations, productivity and ongoing optimization, not just the apparent cost of the target platform.
Finally, avoid treating modernization as an all-or-nothing platform contest. Databricks and SAS can coexist. The more useful question is where each platform can generate the greatest business value while managing cost, complexity and risk.
Sometimes the smartest transformation is not replacing everything. It is knowing what to change, what to preserve and how to make the platforms you choose work better together.
