Full production refresh to development systems and Charm?

Question

Hi SDN Community,
  Where I work we have a policy of refreshing the development systems (ECC, CRM, APO, BI, SRM) on an annual basis with full production system data, HR data is subsequently wiped clean from the development system. 
For each of our systems we have a development system, a QA system and a production system.
The decision to do these full refreshes was taken to ensure that developers and configurers can do decent testing in the Dev environments - prior to transporting to our QA system - to ensure that we have a reasonably stable QA system. Prior to the refreshes - QA was considered too unstable by our business to be used as a good test platform - the full D refreshes solved this problem.
We have recently installed SAP Charm (Change request management) which is a solution manager based product that manages the transportation of objects in change requests - attached to maintenance cycles.
During our first development system refresh we discovered that all open Charm projects (maintenance cycles) were placed into an unuseable status due to the refresh. This means we had to rebuild all of the Charm projects after the refresh - which took a considerable amount of time + resources and delayed project work. We don't want to be in this situation again for our next refresh.
SAPs response to us has been that they have no other customer that does full Development system refreshes - and also has Charm. I wonder if this is accurate, I think what SAP are saying is that they don't have many Charm customers... Is refreshing Development so uncommon?
We are considering products like SAPs TDMS - and alternatives (eg gold client) - but most of these appear a little immature - for refreshing complex system landscapes - such as ours and keeping everything in synch after the refresh.
My questions to SDN -
What do you do - do you do full refreshes to your D systems?
If not - what are the arguments against refreshing D systems (is this considered bad practice)?
Are there any other Charm customers out there in a similar situation to us?
How do you manage the stability of your QA environments and stop the transport into QA systems of untested changes - if your D systems are not similar to you production system
(note we have some 300 active users in just our ECC development system)?
Any suggestions / recommendations as to how to best proceed would be greatly appreciated.
many thanks in advance,
Julian Phillips
Edited by: Julian Phillips on Nov 11, 2008 2:33 PM

Answer 1

Thanks Naushad for your reply,
  I wonder if D refreshes are less common - more due to the additional hardware costs incurred (disk space needed to store full production data is usually pretty large) to do them - than due to avoiding disrupting development - probably a bit of both.
  I did not mention this - but in our refresh we do reimport all transports that we open prior to the refresh - which used to solve our problems - in terms of restoring active changes - but with SAPs Charm system - this approach does not work as the Charm projects are left in an inconsistent status.
We are now leaning towards introducing a 4th set of systems into our landscape - so that we have the following platforms:
Development --->  Pre QA  ---> QA  ---> Production
This approach will allow us to keep both the Pre QA and QA systems refreshed every 6 months or so - and our new Dev system - we will refresh very infrequently (every 5 years perhaps) if at all. We will tie the Charm system to our new development - and this system will then not be impacted by refreshes. This approach means additional hardware cost - but as it happens we have a few spare boxes - so this maybe our best bet.
The core reason for our refresh is so that we will be able to preserve the stability of our QA test platform - which for us is the critical factor here. If QA has poorly tested work in it - we run a higher risk of disrupting other testing and also of this poorly tested work reaching production.
When we used to have a development system as you described and just the single QA box - we experienced frequent instability in our QA box - due to poorly tested working reaching it - and this delayed numerous projects.
Does anyone else have a 4 box setup like this? Anyone else encountered this on an SAP project anywhere? Pros / Cons of this approach?
//Julian
Edited by: Julian Phillips on Nov 12, 2008 8:08 AM
Edited by: Julian Phillips on Nov 12, 2008 8:18 AM