cancel
Showing results for 
Search instead for 
Did you mean: 

Best Practice of copying Production to Development

scott_b
Discoverer
0 Kudos

  Hi everyone.  My management would like some documentation  on the Best Practice of copying Production systems to Development. 

1. In the past, we've setup the clients and connections/interfaces and shrink the database by deleting unneeded production data. Now that there is note 130906, saving the ABAP versions may be easier. 

2. Every two or three years we copy our BIW Production to Development.  This is also labor intensive to set up the development system again with source systems.

3. We've copied our PI 70 system to a sandbox, and again this is labor intensive to reset the PI object names, since the system names are imbedded in the object names.

4. I've done java systems to, so I'm not to concerned about these.

5. There is talk of copying the following Production systems to Development systems - SLD, PI 7.1, Solution Manager, SAP R/3, BIW, MII...some of these make sense, others we question if it is worth it.

  As a note, we copy our SAP R/3 Production instance to our QA environment about twice a year and to another QA system monthly.  We also copy our CRM Production to our QA environment twice a year and BIW Production to QA environment once a year.  We can leverage what we know about copying to PRD to QA, but we want to give them alternatives about copying PRD to DEV.

We'd like to use SAP's TDMS to move data from PRD to DEV.  But unfortunately, that project has not gotten management  attention as being a high priority (yet).

Rather than take my  word for it, is there any SAP provided documentation that would give my management a set of alternatives on their desire to copy our Production systems to Development.

Thanks...Scott B.

Accepted Solutions (0)

Answers (1)

Answers (1)

bxiv
Active Contributor
0 Kudos

From a E2E200 perspective SAP recommends the following landscape:

Maint = Dev -> QA -> Pre-Prod -> Prod

N+1 =  Dev2 -> QA2 -> Pre-Prod -> Prod

Maint is all object versions to remain ideally the same versions, and only transports to fix a short dumping Prod system.  N+1 is where you have implementation/upgrade projects worked on and allow you import the entire project of transports.

Another consideration, when you restore a Prod system to a Dev or new Dev system; you are destroying all of your version info which means your developers can't view or revert changes for the objects.