Copy of production to Development

[Former Member]

My company is looking into copying the production R3 system over the development system. I see that this is not an SAP recommended proceedure, but that there is an SAP note on exporting and reimporting the version info if this is done.

What other information might be lost or problems caused by this process?

I've found several products that are designed to copy a subset of data from one system to another. What are the pros and cons of using one of these products versus a full system copy? (reduced size being an obvious plus for using one of the products)

Thanks,

Brent

[Former Member · Accepted solution]

Have you looked at SAP's TDMS. With this product you can copy a data from a full-sized system over to a development or QA

client. It allows you to do what it calls a Timed Based recuction of the data. That is you can take date from some point forward. I would only contemplate copying over my DEV system, if PROD and DEV had gotten seriously out-of-sync.

[Former Member · Accepted solution]

Currently we are looking at several products including TDMS, GoldClient, SelectRefresh, and a couple of others. The functional teams feel they have a strong need to overlay the DEV system. We are trying to explore all options before taking that step. Our system is less than a year old, but we can already see that doing full system copies is going to become more and more demanding on time and resources.

[markus_doehr2 · Accepted solution]

We have TDMS, we have done quite a few "copies" like this and finally it turned out to be more complicated than initially expected.

The major problems we face are

- DDIC differences between source and target system

Either development is more advanced (has changes the production has not yet) or has some customizing done, that was not "rolled back" and thus the systems behave differently.

- Runtimes of those copy processes

We're actually not able to build a reduced system during a weekend due to runtime issues. It's much faster and almost completely automated to do a full system copy of 1.8 TB in some hours, with, however the drawback, that you have to adapt the system afterwards. But even if we take that into consideration it's faster than using a software to do the copy tablewise on a logical level with reduction.

For specific applications (HR) we have another export/import tool that works and is used a lot.

I can't state on other software tools.

Markus

[Former Member]

The note you're looking for is [130906|https://websmp205.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=130906&_NLANG=en&_NVERS=0].

It is true that SAP does not recommend copying over a development system, and they make clear in that note the risks and issues to be aware of.

Too often (and I'm not suggesting this is the case with you), customers will lose control of their own internal change management processes to the point that the Dev and downstream systems become so far out of sync that the entire TMS is useless. So they jump to the solution of 'starting over' by copying prod back to dev. The better solution in that case is for strict controls to be in place, and necessary authorizations in the system be implemented to avoid these problems from the start.

As for using other products to do an SAP system copy, SAP will only provide support to you if you use one of the SAP methods/tools as prescribed in the respective system copy guide. When you use a 3rd party tool, any issues encountered must be supported through that vendor.

[zobair]

Dear Friends,

We would like to refresh our DEV system from PRD system.

In fact, our DEV system becomes a Sandbox (a lot of transport requests are not released, local objects are created and system is unstable...)

Recently, developers started developing directly in PROD system !!!

DEV, QAS & PRD systems are not aligned anymore.

My question, do we still have to follow instructions describes in note 130906? I mean "Export/Import the version database"? Is there any sense?

My second question is related to this sentence:

The version history of changed SAP objects in particular, and customer objects is important for future SAP upgrades.

What is the impact on an Upgrade? (we are going to upgrade our landscape)

Is there an impact only on the standard objects or also on Z-objects? Latest object version is not enough?

Many thanks for your help.

Regards,

Zobair

[stephane_lamarche]

Hi Brent,

It will also affect your transport domain if it was created in DEV.

You may need to move your transport domain to your QA instance before you do it.

Regards,

Stephane

[markus_doehr2]

Usually, in a three-way landscape you copy your production to the QA system. If you have only two systems (as we have for most of our installations) we copy production to dev - as you would do.

This is a standard procedure and is described in detail in the system copy guides at

http://service.sap.com/systemcopy

Markus