A while back, I responded to a post on an ASUG forum. The question was how others handle the refresh of their development client and data for development and testing. I couldn’t find the original post, but a recent CIO Insight article made me think about my reply to the poster. The original question was precipitated by a statement that the client’s consultant made: that it is a best practice (the misuse of this term really bothers me) to refresh their development client from production regularly. My response to this issue was, it is not a best practice to refresh the development client. In actuality, it is harmful because of the loss of change transport links, modification data (there are ways to restore the modification data, but not the version history) and version history. My other comment was, why would you even want to do this, anyway? Normally, a production environment for a large company can be upwards of 900 GB. I couldn’t imagine copying this amount of data, yet some sites do this on a regular basis. Does it make sense? You weigh in.

Read more: Should You Copy Production Data to DEV and TEST Environments?

It's been a while since we published our white paper on the state of SAP landscapes, but our NetWeaver support team regularly discusses landscapes and possible strategies for setting up clients. While we move forward on this research, I will share with you my thoughts on the reference landscape, which still hold true today. In future articles, I'll expand on this with other new dimension productions.

 

 

 

Read more: SAP Reference Client Landscape

     
Go To Top