For many organisations, SAS still sits at the heart of critical business intelligence and reporting, risk, finance, modelling and analytics.
That’s exactly why executing a complex data migration away from legacy platforms isn’t a simple platform decision.
The business case is often clear: reduce cost, modernise the environment, reduce reliance on specialist skills and create a more flexible analytics capability.
But the practical questions are harder:
- What actually sits within the SAS environment?
- Which workloads are business-critical?
- What can move safely — and what needs to be rebuilt?
- How do you protect reporting accuracy, lineage and control?
- And how do you avoid turning migration into a high-risk transformation programme?
We asked Sean Kenny, Client Director, and Ed Rees, Partnerships Director, to share their perspective on what organisations should understand before making the move.
1. Why is SAS migration difficult?
Sean:
SAS migration is difficult because most environments have not been built in a straight line. They have evolved over many years, across different teams, processes and use cases.
You’re often dealing with a mix of reporting logic, risk models, data feeds, manual workarounds, inherited code and undocumented dependencies.
So the challenge is not just moving code from one platform to another. It is understanding how the environment actually works, who depends on it, and what needs to be validated before anything changes.
In regulated environments, this becomes even more important. If a migrated process produces a different result, teams need to understand whether something has gone wrong – or whether the migration has exposed assumptions that were already there.
2. Why do organisations stay with SAS if they know they need to modernise?
Ed:
In many cases, it is simply because SAS still works.
That’s one of the reasons migration can be difficult to prioritise. If critical reports, models and processes are running, the perceived risk of changing them can feel higher than the pain of leaving them as they are.
However, the longer-term picture is different. Licensing costs, reliance on specialist skills, vendor lock-in, duplicated platforms and limited flexibility can all become harder to justify as organisations modernise their wider data foundations landscape.
3. What are the hidden costs of staying on legacy SAS?
Sean:
Licensing is the obvious cost.
But in practice, the less visible costs can matter just as much:
- Supporting ageing or poorly documented code
- Relying on a small number of SAS specialists
- Maintaining duplicated platforms and processes
- Slowing cloud or Databricks modernisation
- Limiting access to data for modern analytics and AI
- Carrying operational risk in critical but poorly understood processes
- Spending time on manual workarounds that could be simplified
SAS might still be working, but that does not mean the operating model around it is still efficient, scalable or future-ready.
4. Is SAS migration just code conversion?
Sean:
No.
Code conversion may be part of the process, but it’s only one part of the picture.
Successful SAS migration needs to consider:
- Business logic
- Data flows
- Reporting dependencies
- Model outputs
- Validation requirements
- User adoption
- Governance
- Lineage
- Decommissioning
- Operational impact
Treating migration as code conversion alone can create risk, especially where SAS supports finance, risk, regulatory reporting or decisioning processes.
5. What should we assess before migrating SAS?
Sean:
A strong first step is to understand what you have before making any migration decisions.
That means assessing:
- What workloads exist
- Who owns them
- Which processes are business-critical
- Which reports or models rely on them
- Which data sources feed them
- Where manual workarounds exist
- Which outputs need validation
- Which workloads should move, retire, rebuild or be consolidated
- Where the biggest risks and costs sit
This gives organisations a clearer view of effort, risk and priorities before deciding what happens next.
6. Should everything move from SAS?
Ed:
No, and assuming it should is one of the biggest mistakes.
Some workloads will be critical and need careful migration. Others may need to be rebuilt. Some are better replaced, consolidated or retired. And some may no longer be used at all.
The real question is not, “How do we move everything?”
It is, “What should move, what should not, and what should move first?”
7. How do you reduce risk during SAS migration?
Sean:
Reducing risk comes down to taking a controlled, phased approach.
In practice, that means:
- Assessing before migrating
- Prioritising workloads by business value, complexity and risk
- Identifying critical dependencies early
- Involving risk, finance and reporting teams from the start
- Running validation and reconciliation where needed
- Using parallel runs for high-risk outputs
- Improving documentation, ownership and lineage
- Decommissioning safely once confidence is established
This is where risk, finance and reporting teams matter. They help define which processes are critical, what needs to be validated, where controls must be protected and where auditability matters.
The aim is not to move quickly at any cost. It is to move with control.
8. Where does Databricks fit into SAS migration?
Ed:
For organisations moving towards modern data platforms, Databricks can provide a more scalable and flexible environment for analytics, data engineering and AI.
But moving from SAS to Databricks should still start with a clear understanding of what exists today, how it is connected and which controls need to be protected.
Simply moving workloads to Databricks isn’t the goal. The real value comes from creating a more accessible, better-governed data environment that supports analytics, AI and future growth.
9. Can automation make SAS migration easier?
Ed:
Automation and tooling can help reduce manual effort, improve visibility and support migration economics.
But tooling is not a magic wand.
The strongest approach combines automation with experienced delivery expertise. Tooling can help assess and accelerate parts of the journey, but human judgement is still needed to understand business logic, risk, validation, prioritisation and adoption.
10. What is the right first step?
Sean:
The right first step isn’t committing to a migration programme. It’s getting visibility of what you have today.
A SAS migration assessment helps organisations understand what exists, what matters most, where the risks sit and what a practical migration route could look like.
That gives leaders the clarity they need to make decisions based on evidence, rather than assumption.
11. What does a good SAS migration roadmap include?
Sean:
A good roadmap should clearly show:
- The current SAS environment
- Key workloads and owners
- Business-critical processes
- Risk and complexity levels
- Migration priorities
- Treatment paths for each workload
- Validation and reconciliation needs
- Governance requirements
- Decommissioning approach
- Estimated effort and sequencing
It should be practical, phased and grounded in business value, not just technical sequencing.
12. What is the real opportunity?
Sean:
SAS migration is often triggered by cost, platform change or cloud modernisation.
But the opportunity is bigger than that.
Done well, it can reduce legacy complexity, improve transparency, strengthen data governance and management, reduce reliance on specialist skills and create a stronger foundation for modern analytics and AI.
Done badly, it can create disruption and weaken trust in critical reporting and decision-making.
That is why SAS migration needs to be treated as a data, risk and business leadership issue, not simply a technical deliedery task.
For more of Sean’s insights on SAS migration – read his recent article on SAS migration Made Easy.
How Dufrain and T1As Alchemist can help
Dufrain has partnered with T1A, the company behind Alchemist, to help organisations take a more structured, assessment-led approach to SAS migration.
Together utilising Alchemist, we help organisations understand their current SAS environment, identify complexity, prioritise workloads, reduce uncertainty and build a controlled route to modern data platforms such as Databricks.
For organisations reviewing legacy SAS, the first step is simple:
Understand what exists, what matters most, and where migration can deliver the greatest value while keeping risk under control.