by Bob 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 various organizations transition from SAS, SPSS and/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 to use than other software. But if you have some people who use something like SAS only occasionally and view it as hard to use, you might consider getting them something other than R. Menu-based solutions such as SPSS or
R Commander may be a better fit for them. If they want to continue using SAS while lowering your licensing costs, you might consider the SAS implementation used in WPS (see World Programming).
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 Analysis Software). Keep in mind that attempting to motivate people to change by criticizing their current choice is likely to backfire. People’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. Choosing to use R packages that provide output similar to your current software choice will help smooth the transition. Good sources for training are listed here: my own on site training, Training and Consulting Partners – RStudio and here: R for SAS, SPSS and STATA Users | DataCamp. Books that help with the conversion process include:
R for SAS and SPSS Users, Muenchen
SAS and R, Kleinman & Horton
R for Stata Users, Muenchen & Hilbe
R Through Excel, Heiberger & Neuwirth (for those who use the SAS Excel plug-in)
4) Provide in-house tech support. Before training a whole team, get one in-house expert trained to act as a consultant to others. Make sure this person is well known by everyone and has time freed up to provide help.
5) Match your staff’s current work style, work flow and output. This is a particularly complex topic. Some examples: if your people are running SAS from the Excel plug-in, get the the R plug-in; if they’re using Enterprise Miner, 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 LaTeX text processor at the same time (LaTeX is wonderful and very popular among R users, but it’s a mess to learn that and R at the same time). Instead, use an approach that generates Word output.
6) Migrate one step at a time if possible. For example, if you use SAS/ETS for forecasting, consider replacing just that one piece. When finished and successful, choose the next product, saving SAS/Base for last.
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 SAS 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, make sure to involve your own staff in the process so you don’t end up with code that’s almost impossible to maintain.
I have found that following these steps helps during conversions to R. It’s a big job, though, so allocate plenty of time to it. Good luck!
Bob, with all due respect it sounds like a lot of effort to replicate current functionally; essentially to a lesser platform. I don’t see the ROI. Many use the licensing of SAS as the bulk if not the entire argument. ROI is a dual equation; cost and benefit. While you may save on initial cost somewhat, the delivery does not justify the effort. The ease of use of SAS (SAS/EG, SAS/DI, SAS/EM and all the other products), will save much money in the time of development versus other products. One of my clients compared Revo R Suite to a SAS Grid. SAS exceeded the cost by ~10%, but the capability of Revo R was at best 20% of the SAS Grid and packages, especially when Grid performance is factored. They made the correct decision and went with the Grid. Point of fact, SAS Grids are being installed everywhere in every industry. Open-source R is at best a niche product in an Enterprise world (private or public). So you must look at how it evolves in the proprietary form. SAS is a moving target as are the other fine products you mention (I particular enjoy Stata too). It is ironic that I spend a good deal of my time converting from R to SAS or in streaming R packages within SAS because of performance or validation of results. The tool needs to fit the project, not forced because of personal preference. Enjoy!
Hi Mark,
You make some really good points. Each software package, whether open source or commercial, may be best for the needs of a particular organization. I’m a bit of a software “junkie” and I enjoy working in a wide variety of packages.
Cheers,
Bob
Mark Ezzo: I don’t see this post as arguing that anyone *should* migrate to R, just as giving advice in case they have decided (hopefully on sensible grounds) that they want to migrate.
Hi Ben,
Your field is probably a prime example of one for which R offers very distinct advantages. Can you “guestimate” what percent of the analytic methods in your book, <a href="Ecological Models and Data in R
“>, have no counterpart in mainline commercial stat packages?
Cheers,
Bob