For a new Production environment, I agree - a DB copy is the most efficient and effective migration means. But on an existing production system, that's not practical, because you would wipe out existing data. He didn't specify which was in play, but since it was already at 4 GB, I'm assuming that it already existed with considerable data. I can see why one would be tempted to use Migrator in this instance, but experience tells me that down that path there be dragons...
Rick On 8/23/07, Garrison, Sean (Norcross) <[EMAIL PROTECTED]> wrote: > > ** > > Do a database copy instead of a migration … the only drawback is > something that the e-mail server would be pointing to your prod e-mail > accounts … but that would be easily fixed. > > > > Sean > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Koyb P. Liabt > *Sent:* Thursday, August 23, 2007 1:15 PM > *To:* [email protected] > *Subject:* Overwriting Code > > > > ** > > We have 3 environments and a SANDBOX. Code tested successfully in QA and > was imported into Production and broke workflow. > > To fix, we ported code from Prod to a SANDBOX, then to QA, then to Prod > again. The technical staff took 25 hours for our OOB applications with > minor customizations (AR System 7, Change, Asset, and SLA). > > To prepare we did the following: > > 1. Prod database has been restored into QA and Dev for synchronized > environments. > 2. Generated .def files from QA for all objects prior to every > migration. > 3. Loaded the "new code" to development > > It took over 25 hours for the following: > > > > a) migrate new objects from .def files into QA > > b) restore the QA database with "new objects" into Dev > > c) restore the QA backup to QA (to undo the build that failed > changes in QA). > > Our environment: > > The Prod database increased from 4GB to 17GB and after restoring it into > Dev, where the Migrator Utility lives, it looks like Migrator cannot handle > the workload when it targets the development server (itself). The Dev server > is a virtual machine with 2 CPUs and 4GB of RAM > > Total this took 50 hours. > > When the code was restored to productions - it was to be restored to the > previous state. However, we found code was wiped out again in production. > Apparently we went a few versions back, and the code we are now viewing is > from months ago.. The person migrating said that code could be missed and > introduce new bugs - that is the risk we take. Migrator has a report that > shows failure or dropped code. Validating the results of the migration - > shouldn't this protect us and prevent this from happening? > > Also are we doing something wrong here?I have never had migrations take so > long. Nor have I ever seen code wiped out all the time. With each > migration things seem to go wrong. > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
