R and most of its CRAN modules are licensed using the GPL.
In many companies, legal departments go crazy if you propose to use anything that is GPL in production... It's not reasonable, but you'll see they love Apache, and hate GPL. Before going into production, make sure it's okay with the legal department. (IMHO you are safe to use your modified code for internal products. Integrating R into your commercial product and handing this out to others is very different. But unfortunately, many legal departments try to ban all use of GPL whatsoever.)
Other than that, R is often really slooow unless calling Fortran code hidden inside. It's nice when you are still trying to figure out what to do. But for production, you may want maximum performance, and full integration with your services. Benchmark yourself, if R is the best choice for your use case.
On the performance issues with R (I know R advocates are going to downvote me for saying so ...):
Morandat, F., Hill, B., Osvald, L., & Vitek, J. (2012). Evaluating the design of the R language. In ECOOP 2012–Object-Oriented Programming (pp. 104-131). Springer Berlin Heidelberg.
(by the TraceR/ProfileR/ReactoR people from purdue, who are now working on fastR which tries to execute R code on the JVM?) states:
On those benchmarks, R is on average 501 slower than C and 43 times slower Python.
Observations. R is clearly slow and memory inefficient. Much more so than other dynamic languages. This is largely due to the combination of language features (call-by-value, extreme dynamism, lazy evaluation) and the lack of efficient built-in types. We believe that with some effort it should be possible to improve both time and space usage, but this would likely require a full rewrite of the implementation.
Sorry to break the news. It's now my research, but it aligns with my observations.