Migrating to R - Challenges and Solutions
Migrating to R isn’t just a technical rewrite; it’s a cultural and operational shift. I’ve been involved in multiple projects involving migrating to R from a previous solution like SAS or Excel, sometimes scoping out the roadmap for a complete transition, and other times doing the work itself on subcomponents of a wider project within a larger organisation. Every project is different, but common patterns (and pitfalls) emerge.
It’s easy to assume that it’s just about writing code, but in reality there’s more to consider here - it’s about culture, politics, and momentum as well.
Why Migrations to R Are Harder Than They Look
There are lots of reasons people choose to migrate to R from other solutions, and these tend to be a mix of wanting to move away from expensive proprietary licenses, the skillsets of new data analysts and scientists skewing more towards modern technologies like R and Python, and wanting to implement more robust practices for code being used to support wider business processes. Factor in the ability to access cutting-edge statistical methods, interoperability with the wider modern tech stack, and scope for flexibility and customisation, and it’s hard to see why not to move.
Complex existing codebases
One of the common themes I’ve seen in migrations is large codebases which feel vast and difficult to tackle. Many organisations depend on undocumented production code, with little understanding of its complexity or volume.
Skillset gaps
Skillsets are often mismatched with few people confident in both SAS and R. Much of the time, people are supporting legacy code which they’ve inherited from other programmers who have since moved on to other teams or left the organisation entirely and things may work but people don’t know how or why.
Missing practices (version control, testing)
It’s also common to see codebases which just work but don’t follow modern practices such as using version control to track code changes and manage multiple people working on the same code, no tests or continuous integration and so the intended behaviour isn’t always well understood, is prone to bugs, and it’s impossible to confidently make changes without breaking something.
Organisational buy-in
Another challenge can be organisational commitment and buy-in. When there isn’t agreement around the change is necessary, it can be seen as time-consuming and difficult. If these transformations are not adequately supported and staff are expected to change tools without training or time to upskill, resistance is inevitable. Learning to program in R can be a rewarding experience, but without the proper setup can just be an annoyance.
It’s not as simple as taking code line by line and rewriting from one language to the other. Take the example of moving from SAS to R, the different frameworks have entirely different approaches, and a direct translation tends to leave people with inefficient code. Modern approaches like LLMs can help generate the equivalent code when switching over, but often a broader view is needed to do a good job of a transformation.
How to Approach Migration Effectively
With a systematic approach which focuses on the right areas, it’s possible to do a successful migration in which the benefits are realised easily.
Audit codebases: size, complexity, risk
One project I worked on was scoping out a migration for a large organisation which depended mostly on SAS, but had some R users, and had made the decision to transition away from SAS with a clear deadline for completion. I conducted an in-depth audit on their current setup and advised on the path forward.
I started off by identifying the different stakeholders in the organisation. This is important as they tend to have divergent needs - people who are writing the code, people who are making decisions based on the results of their analyses, and people who are deploying the code in production environments.
Auditing what you have is critical. As part of this project, I analysed the entire SAS codebase, scanning the code to work out how much there was and what the different SAS proc calls were. Auditing the code gives a clear view of the scope and complexity.
When you have SAS code which uses, for example, mostly proc SQL, this is simpler to convert to the equivalent SQL in R. There are specific challenges which become apparent when you’re dealing with statistical analyses; there are some differences between R and SAS in terms of default parameter values and implementations of methodologies, but this can be tackled by identifying the key procs, and robustly testing outputs to compare them. There are also excellent projects like CAMIS which provide guidance on the differences between the different languages.
These audits must go beyond simple code analyses though; it’s also important to prioritise different areas of the codebase and distinguish between what is used in production versus what is more ad-hoc code.
Identify quick-win proof-of-concept projects
At this point, it’s often helpful to identify good candidates for proof-of-concept projects which allow clear demonstration of value and evidence of tangible benefits to the business. The best place to look is usually found by interviewing stakeholders and getting an idea of what really is difficult in their day-to-day work, or something which is particularly inefficient. This is where things like Shiny apps are excellent for transforming a time-consuming and manual process into something more engaging and easy to use.
In one project, users relied on a painful command-line workflow involving multiple configuration files and obscure commands. We built a Shiny app to wrap around this process with intuitive dropdowns, clear instructions, and a clean interface - massively improving usability and reducing error.
Quick wins demonstrate value and generate the interest and engagement needed for a migration.
Culture Matters More Than Tools
Users are where it’s important to focus most of your efforts.
Supporting users through change
Users who are comfortable and confident in their existing tooling can be resistant to having that taken away from them. Change can be seen as disruptive and lead to pushback. Giving people quick wins in R is important so they can quickly build confidence.
Training, mentoring, lightweight standards
A great way to get started is via training courses but there’s more that can be done here. Provide them with training on using R, and further support from experts - whether internal or external. Ensure that code is reviewed, but give clear guidance on how to conduct a good code review - make sure that it empowers and enables people rather than leaving them feeling criticised and incompetent.
Support can take different forms: one-on-one mentoring, team office hours, or embedding R champions within teams.
Building community and momentum
Either way, change happens when people understand the benefits and feel supported. And sometimes you just have to make it fun - for example, by running hackathons where people can blend new skills with creativity, or bringing in external speakers can also generate enthusiasm. Ultimately, you need some sense of community so people feel like they’re not just working away in isolation.
How I Help
I really enjoy these kinds of projects as it’s rewarding to see folks enthusiastically engage with tech which is new to them.
Advisory, proof-of-concept, guidance
On these kinds of projects, I tend to work in the role of advisor and implementer. What works well is to implement some kind of proof-of-concept project to both demonstrate value and then use as a prototype for what good looks like, and then provide guidance and support to teams updating their own codebases. I don’t tend to offer full codebase rewrites - the point is to enable teams to be self-reliant and empower them to be able to move independently in the longer term. That said, sometimes it makes sense for me to rewrite the more complex areas or provide additional support in terms of code reviews and introduction of best practices.
Training options
I also offer training courses and support - whether that’s introductory R, more complex topics like working with version control, writing R packages, or a more bespoke course tailored to your needs.
The key thing here is providing structure and clarity, planning out the various stages, helping you identify what actions and infrastructure you’ll need in each part, and working out a path to make this work for you and your organisation.
Get in Touch
If you’re planning a migration or are stuck partway through one and need experienced support, I can help you move it forward. Get in touch.