Removing DV environment

Hello,
We are considering removing/deleting DV and using PY/CRP as our development environment in order to free up space on our AS/400. We use XE and are on SP 23. Has anyone been through this procedure? Any info/advice/recommedations would be appreciated.
Thanks.

Better idea:

Remove packages, purge business data if you need to but you really shouldn't be thinking about removing an environment that: A- is in your lifecycle path, B- is defined in OMW transfer activity rules, C- may contain development that you do not have anywhere else.

I wouldn't even consider doing this. Do some cleanup, purges, etc. first. Go find old full packages, delete the pristine packages, heck delete the pristine Path Code on the Enterprise Server (not the environment and not on the Deployment Server) since you can always build and deploy a new pristine package if you really need to run something in pristine. Take a look at the tables in pristine. Do they have demo data in them? If so delete that data instead.

In sum, there are many things you can do before you remove an environment like DV.




[ QUOTE ]
Hello,
We are considering removing/deleting DV and using PY/CRP as our development environment in order to free up space on our AS/400. We use XE and are on SP 23. Has anyone been through this procedure? Any info/advice/recommedations would be appreciated.
Thanks.

[/ QUOTE ]

Nikki,

First, welcome to JDEList.

Second, We, because of a variety of factors, are using the PY environment for our development and have done so for a few years. However, we don't do a great amount of development work. I have had to modify the OMW rules as well. The discomfort is not that great, but I would prefer to have a separate development environment. The DV environment is still defined within Xe, but some of the schemas/owners do not exist in the database. The situation is the same for the JD or pristine environment. With our upcoming upgrade I am expecting to get all the environments (Pristine, Development, Training etc. or their 8.11 equivalents) back and in action.

That being said, I agree with Brother Of Karamazov, and do not recommend our situation. Especially if it is to be a temporary/interim solution. The data of the PY environment has become highly disorganised and refreshing it from PD could damage some of the developments in progress. We thus are limited to the testing we can do before puting any devlopment into production. We have not had any major catastrophes, only some relatively minor problems, but the risk is significantly greater.