Hi You does not need to freeze anything. The requirement from the inital poster was to set up a new server.
With a new server you can move all your data. When the first load is done, you start it over again. The next run will take just a few hours. And when your ready to switch production to your new server, you run the rrrChive again. Using this approach you can have a cut-over in just av few minutes. -- J 2014-11-18 12:07 GMT+01:00 Sean Harries <[email protected]>: > ** > > Hi Kiran, Jarl, Listers, > > > While RRRchive has some great improvements in terms of handling the > deletion of data and configurability, the main issue you're likely to face > is performance. If you are able to agree the data freeze and data catch up > management around a 20 day delta process then that is OK. On many of our > projects, we found that was difficult to agree with the business and stake > holders so we developed the Customer Move Tool. > > > The Remedy API is great at a number of things, but bulk data migration is > not among them. Using RRRchive, it previously took us over thirty days to > accomplish a full data migration from a full copy of a Production system. > After that migration, we then had to perform multiple delta migration runs > leading up to go-live. The inherent limitation of the Remedy API has been > recognised by BMC, and for the DDM product, some Forms like Audit and > Worklogs are now migrated at the database level. > > > The CMT Tool has a number of advantages over other tools currently > available; > > 1. Moves data at the database level - we are typically able to move an > entire ITSM application within a single day, rather than several weeks. The > final delta migration for the Production cutover is less than an hour. > > 2. Automated discovery and analysis - CMT will discover a Remedy > application including customizations and map the data. Any discrepancies > like mismatched field lengths, missing enums or missing fields are > identified and presented in the CMT Workbench web UI. This is a distinct > advantage over other tools, which require you to mess about with XML files > and will not automatically identify differences or pick up customisations. > For a lightly customised system we would typically be ready to move data > within a couple of days - which believe me compares very favourably to the > effort expended in previous upgrade projects I've been involved in! > > 3. Relationship Aware – while other tools migrate on a simple form-by-form > basis, CMT builds a data model of your Remedy application which it uses to > migrate data.. This opens up a number of capabilities such as being able to > migrate individual ITSM companies between Remedy systems, consolidating > multiple Remedy systems into a single multi-tenancy system, performing > archiving of data during data migration, etc. > > 4. Flexible and Powerful Mapping and Transformation– using the CMT web > user interface you have full control over the way data is migrated and can > transform and map data to handle a range of scenarios, including populating > new fields with defaults, transforming Product Catalog data, selectively > mapping data to new Forms, fields or entities. > > > Finally CMT handles data deletions, has outstanding exception management > (no more searching through log files) and very good operational > capabilities Please let me know if you'd like to discuss this further ( > sean.harries@alderstone,com) or you could sign up for one of our webinars > at http://alderstone.com/cmt-events/ > > > Cheers > > Sean > > > > *Sean Harries* > Alderstone Consulting Ltd > > > > Revolutionise your management of BMC Remedy ITSM Services with CMT > <http://alderstone.com/cmt/> > > > Mobile: +44 (0)7976 558048 > Skype: seanharries > MSN: [email protected] <[email protected]> > e-mail: [email protected] > Linkedin: http://www.linkedin.com/in/seanharries > > > > On 17 November 2014 18:14, Jarl Grøneng <[email protected]> wrote: > >> ** >> Hi >> >> We'r in the same process. 150Gb data, estimated 20 days in >> initial transfer using rrrChive. Nest load will take next to nothing. >> >> >> -- >> J >> >> 2014-11-15 8:10 GMT+01:00 Kiran Patil <[email protected]>: >> >>> ** >>> Hi All, >>> >>> We are doing upgrading customer Remedy 7.5 to 8.1 >>> Here is background - >>> 1. Customer has 750GB-800GB transnational data of Incident, Change, >>> Problem. >>> 2. We are not doing in-place or staged In-Place upgrade. We will >>> implementing new 8.1 >>> system and migrating data from Remedy 7.5 to Remedy 8.1. >>> 3. Core Req: >>> 1 - Customer wants all historical data to be migrated >>> into Remedy 8.1 along with >>> work logs (with attachments), Related other tickets, >>> task, SLA, Approvals (For change), audit log. >>> 2 - Customer wants to retain old ticket number in system >>> and dont want new >>> ticket Id to be generated during migration process. >>> >>> Our Solution: >>> 1. Using UDM we can import transaction data and disable new Id creation >>> and can >>> retain old ticket number however we cannot control on C1 to retain >>> from old system. >>> UDM approach has 64000 records limitation per batch so migrating >>> 750GB will take >>> months or may be years to migrate data. >>> >>> Is anyone has migrated ticket data using this approach, I would like to >>> hear issues/challenges occurs during activity. As per BMC somehow they dont >>> recommend it. >>> >>> Any suggestion or idea will be welcomed. >>> >>> Thanks >>> Kiran Patil >>> >>> >>> >>> >>> >>> >>> >>> -- >>> *Regards* >>> >>> *Kiran PatilMobile: +91 9890377125* >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
