Helping Your Organization Migrate to R

by Robert A. Muenchen

As the R programming environment has grown in capability and popularity, so have the number of organizations planning to migrate to it from proprietary tools. I’ve helped members of many organizations transition from SAS, SPSS, or Stata to R (see Workshop Participants), and the process typically involves the following steps:

1) Begin with the most important question: who should you migrate to R? Learning R is not a trivial task (see Why R is Hard to Learn). However, once mastered by people who use it regularly, I think it’s easier than other code-based software. But if you have some people who program in a language like SAS or SPSS only occasionally and view it as hard to use, you might consider having them try one of the menu-based front-ends to R. If you decide to have some people continue using SAS while lowering your licensing costs, you might consider the SAS implementation used in Altair’s SAS Language Compiler. That version of the SAS language has an extensive feature set, and the Community Edition is free.

2) Motivate people to migrate. Discussing your current software budget may help. Showing your staff the growth of R’s capabilities and popularity may also help (see The Popularity of Data Science Software). Keep in mind that attempting to motivate people to change by criticizing their current choices is likely to backfire. A person’s choice of software is very personal, and criticizing it is like telling them they have the wrong religion.

3) Use training & documentation that leverages what they already know, that speaks their language. A trainer who knows both your existing environment and R can convert what the analysts currently know rather than simply starting from scratch (note that this self-serving advice!) There are two parts to this process: learning the new R code and learning to interpret the new R output. Using R packages that provide output similar to your current software choice will help smooth the transition.  Good sources for training are listed here. Books that help with the conversion process include:

4) Provide in-house tech support. Before training a whole team, get one in-house expert to act as a consultant to others. Make sure this person is well known by everyone and has time freed up to provide help. Keep in mind that expertise in R and expertise in training are often mutually exclusive skills. The greater a person’s expertise, the less likely they will understand why anyone would have problems learning it!

5) Match your staff’s current work style, workflow, and output. This is a particularly complex topic. Some examples: if your people use menu-based tools like SPSS, Minitab, or JMP, consider graphical user interfaces for R; if they’re using a workflow-based tool like SAS Enterprise Miner or SPSS Modeler, consider a similar interface that controls R such as the KNIME Analytics Platform. If Microsoft Word is their main word processor, don’t complicate the conversion by switching them to text processors such as LaTeX or RMarkdown at the same time. Text processors are very popular among R users, and rightfully so.  But trying to get people trained in both simultaneously can have disastrous results. Instead, cut and paste R’s monospaced output into Word or use an approach that generates Word output and saves other transitions for later.

6) Migrate one step at a time if possible. For example, if you use SAS/ETS for forecasting, consider replacing just that one piece. I maintain a list of SAS and SPSS products and the R packages which are their approximate equivalents here. Consider calling those R functions from within your current software, allowing your staff to continue to use their current software for data management. When you have finished migrating that type of task, choose the next product, saving SAS/Base for last. Keep in mind that Altair SAS Language Compiler (SLC) is an implementation of SAS at a much lower price than SAS Institute charges. SAS Institute employee Phil Weiss thoroughly compares SAS with SLC here. However, he doesn’t point out that people often continue to use SAS PROCs that are pretty old (e.g., PRINT, SORT, SUMMARY, REG, ANOVA), so the list of PROCs missing from SLC may not affect your migration.

7) Convert your programs or use conversion services. If your programs are all in production, this could be a huge job. However, if you mostly use your current tool for new research tasks, you may not need to convert old code from which you just needed a solution.  Be careful to avoid line-by-line conversion; think like R (e.g., avoid for- and while-loops in R). When using external conversion services, involve your staff in the process so you don’t end up with code that none of your staff know well enough to maintain easily. Large language models, such as ChatGPT, can automatically convert your current code to R, but you need to verify carefully that they generate the same results.

I have found that following these steps helps during conversions to R. It’s a big job, though, so allocate plenty of time. Good luck!