is a system copy to development a best practice?

[Dave_S]

("Refresh", as I use it here, refers to a system copy.)

We typically refresh our sandbox and pre-production test systems from production. Not often, since its a non-trivial amount of work (although our functional/business teams don't seem to realize that ), but we've got the process down. The production DBs also total around 8-9 TB, and its not practical to store too many copies of that. The full environment includes the core ERP 6 system (HR, PY, FI, CO, parts of PLM), SRM 5, BI 7, and two portals (employee and vendor), each with development, QA/test, pre-production, and production.

We have never refreshed our development environment, mainly since that version history and test data.

We recently had a project consultant request that we refresh development from production, and claim doing so was a "best practice". The project might significantly reconfigure FI, but everything else is out of scope.

Although refreshing the development system/environment can be done, should it be? What kind of circumstances might make it a good idea? Is it considered it a "best practice" by others? Why?

(Cross posted to the [ASUG Systems Management forum|http://hosted.jivesoftware.asug.com/community/sig_communities/business_integration__technology_%26_infrastructure/systems_management_sig].)

Thanks,

Dave

[Dave_S]

There are several responses on ASUG:

http://hosted.jivesoftware.asug.com/thread/35134?tstart=0

[Former Member]

Well i cannot view the ASUG discussion but here is my 2 cents:

cons:

- versions history has to be saved prior to copy

- cost (additional disk space, backups, cpu/memory)

- the production data will age pretty fast, so the copy has to be done on a regular basis

- lots of interfaces to other systems will have to be corrected, risk of connecting to prod systems during the copy process

- the dev system will be unavailable for several days during the copy

pros:

- real data on the prod system, no need to manually generate data

- most performance issues can be discovered at design time, given the hardware is comparable to the prod system

In my opinion regularly copying the prod system to dev is not best practice. Personally i would never do it because of the cost and amount of work needed to do it.

Best regards, Michael

[Former Member]

Hi,

mho, I agree completely with your pros and cons but not with the conclusion.

IMHO, each SAP customer has different needs and possibilities, there is no absolute best practice.

In my company, we do refresh the DEV system from the production for R/3, but not for PI or CRM.

It depends !

Regards,

Olivier

[Former Member]

Agree, it certainly depends. If for example the system is small and the environment is simple, and the copy can be automated to a large degree, then most of the cons are invalidated. BTW i forgot a possible pro:

- the dev system is refreshed on a regular basis, so unwanted developments are cleaned away automatically

Regards Michael

[Former Member]

Hi,

I agree that this is a case of "it depends." I would never say, however, that refreshing DEV is a best practice. On the contrary, I would say that never refreshing DEV is the best practice, unless a very, very strong case can be made to do it. There are possible exceptions where DEV is refreshed, but these should stay as they are, exceptions, not the rule.

When I first was a "fresher" many moons ago, refreshing DEV was considered a major no, no and was only done in extreme cases where system administration management had gotten out of control -- creating objects in PRD that weren't in DEV, too hard to synchronize, etc. It is somewhat different now, but it is still not something I would do, and I would personally never consider it a "best practice" to do so.

Best Regards,

Matt