Something I haven't seen mentioned but is very important as well is one needs to be careful when crossing over multiple major versions. The data models from ITSM 7.5 to 8.1 are not fully equivalent so if you just straight try and move all the data from a 7.5 system into an 8.1 system (A -> A), expect some breakage somewhere, typical examples could be changes with multiple approvals that are pending (in 8.0/8.1 there was some under the hood changes as well as consolidation of change approval processes). This is one of the reasons for a tool like DDM that does the version by version conversion in steps (albeit painfully in the setup and execution sometimes with workarounds needed but it's getting better and better documented with every release it seems).
Straight shot tools from point A to point B are great for keeping say a QA environment in sync with PROD since they will be at the same version (and other similar requirements) but unless you are sure of your data model (e.g you are running custom apps), a straight shot movement of the data from an older BMCs ITSM suite has some risks in an upgrade scenario that need to be fully vetted as breakage can and do happen very subtly sometimes. On a different but related topic, that CMT tool Sean mentioned a few emails up looks pretty neat, kinda how DDM 'should' be if what it says is all true :) On Tue, Nov 18, 2014 at 7:23 AM, Jarl Grøneng <jarl.gron...@gmail.com> wrote: > ** > 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 <sean.harr...@gmail.com>: > >> ** >> >> 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_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > -- :wq cuga _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
