Meta-Update is not yet a BMC Software Tested and Supported Tool – I believe that those are two different things. I have been called about it and am investigating it now.
We have certainly quite a few customers willing to give references, have been a BMC partner for years, and have also migrated data for BMC – some time ago, I think an ITSM 6.1 to 7.1. It was certainly with the Asset form – pre CMDB. At that time, the foundation data was imported by BMC through a forerunner of what turned into the data management tool. With Meta-Update, one of our first customers was able to migrate from 5.5 with a “heavily customized, multi-tenancy ITSM” to 7.1 – by themselves, even migrating SLA to SLM data against my recommendation. (I said that the concepts had changed and it would be better if they manually create them) We successfully migrated a running Clarify Help Desk to a running ITSM so that after Clarify was shut down on Friday, the analysis came in on ITSM with new logins, a new GUI, but their tickets and tasks waiting for them J We have successfully migrated an ITSM 7 to 8.1 including all foundation data, product and operational catalogues, ticket data, even changing Changes of type Release to the Release module, with the changes Tasks becoming Activities. All this for a company that changed its name and went from a single Operating Company to nine along with its people, a reorganisation of the CTI, Support Groups, etc. This resulted in our <http://www.softwaretoolhouse.com/product/PkgMigItsm/index.html> ITSM migration package – a set of almost 100 scripts and a 150 page document, that explains how to use the scripts, set up Excel mapping files, and tailor the scripts to your wishes. Obviously, when all internal references are to remain the same, none of this complexity is required, and a single, simple, Meta-Update script will handle any table: [Table-Copy] Query = @Source-Server, Source, $Arg, Table-Name$, $Arg, Query$ Update = Target, $Arg, Table Name$, ‘1’ = “$Source, 1$” AssignNew = Table-Copy-AsgNew Assign = Table-Copy-Asg Merge = Yes, NoWorkflow [Table-Copy-AsgNew] @Cmd = Copy, Source [Table-Copy-Asg] @Cmd = Copy, Source, Skip: 179, 1 That’s more or less the only script needed. (In fact, the script is a tad more complex, there may not be a 179 for example, but a customer wrote the script.) The good thing is that Meta-Update now comes with an “Automation Script”. This fires and tracks jobs of transfers in multi-threaded batches. Yes, any transfer through the API will take time compared with SQL, and with a tool like Meta-Update, which offers unparalleled, simple access to Remedy data, be slower still. But the Automation script does take the pain out of it, and gives you control over dates, batches, etc. One company archived millions of backlogs tickets etc in one month and the automation script runs monthly for about 24 hours. Each archive ticket is checked for associations preventing archival, and is archived in a complete tree with all dependencies before deletion. Scripts can be simple like the above, or complex, like the one that takes changes of type release (and their tasks, associations, and converts them and all their dependencies to the release module with activities, manifests and associations. Luckily, Meta-Update does include a single stepping, breakpoint debugger. Meta-Update has an extremely light foot print. No server changes are needed at all. Simply unzip and set up your Remedy Access and you’re good to go. Take a look or a try. Trials are free, are the full package, including a very useful query, delete, and schema utility (used for our freebie ITSM Forms and Fields spreadsheets), come with a <http://www.softwaretoolhouse.com/product/SthMupd/mupd_liveinstall.html> Live Install, and are only limited by time (but are expected to be for a development machine). Included are a query, delete, and schema utility. As an Ozzie consultant once said, “I love Meta Update and still believe every large Remedy implementation team must have it in their kitty.” Cheers, Ben Chernys Senior Software Architect logoSthInc-sm Canada / Deutschland Mobile: +49 171 380 2329 GMT + 1 + [ DST ] Email: <mailto:Ben.Chernys_AT_softwaretoolhouse.com> Ben.Chernys_AT_softwaretoolhouse.com Web: <http://www.softwaretoolhouse.com/> www.softwaretoolhouse.com We are a BMC Technology Alliance Partner Check out Software Tool House's free Diary Editor and our Freebies Section for ITSM Forms and Fields spreadsheet. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. Meta-Archive does ITSM Archiving your way: with your forms and your multi-tenant rules, treating each root request as the tree of data and forms that it is it is. Pre ITSM 7.6.04? Clarify? Roll your own? No problem! You can keep your valuable data! <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Terje Moglestue Sent: November-18-14 12:29 To: arslist@ARSLIST.ORG Subject: Re: Ticket Data Migration from 7.5 to 8.1 ** I am using 3rd party tools and more all the time. It saves me lots of time. Within this area, we need a BMC Software tested and a supported tool. There is no need for an over engineered tool with too many options and alternatives. I would expect that BMC could “quickly” come up with an approved and supported solution. This is not a new topic. It is not unrealistic requirement to get historical data migrated where all reference numbers are intact. ~ Terje From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Sean Harries Sent: Tuesday, November 18, 2014 11:08 AM To: arslist@ARSLIST.ORG Subject: Re: Ticket Data Migration from 7.5 to 8.1 ** 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 <tel:%2B44%20%280%297976%20558048> Skype: seanharries MSN: <mailto:sean.harr...@alderstone.com> seanharr...@alderstone.com e-mail: <http://sean.harr...@alderstone.com/> sean.harr...@alderstone.com Linkedin: <http://www.linkedin.com/in/seanharries> 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 Patil Mobile: +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_ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3485 / Virus Database: 4189/8589 - Release Date: 11/17/14 _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"
smime.p7s
Description: S/MIME cryptographic signature
