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: seanharr...@alderstone.com <sean.harr...@alderstone.com> e-mail: sean.harr...@alderstone.com Linkedin: http://www.linkedin.com/in/seanharries On 17 November 2014 18:14, Jarl Grøneng <jarl.gron...@gmail.com> 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 <kiranpatil....@gmail.com>: > >> ** >> 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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
