Re: Ticket Data Migration from 7.5 to 8.1
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
Re: Ticket Data Migration from 7.5 to 8.1
Thanks you so much to all for providing valuable input on data migration. We have tested and verified integrator spoon will be best suited for our requirement. As per our customer's requirement they are also forward to retain foundation data ids from earlier version to. 8.1 so data access control integrity with ticket will remain same. Please provide your valuable input. Regards Kiran Patil On 18-Nov-2014 6:27 pm, Curtis Gallant cgall...@gmail.com wrote: ** 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
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 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
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,commailto: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 CMThttp://alderstone.com/cmt/ Mobile: +44 (0)7976 558048tel:%2B44%20%280%297976%20558048 Skype: seanharries MSN: seanharr...@alderstone.commailto:sean.harr...@alderstone.com e-mail: sean.harr...@alderstone.comhttp://sean.harr...@alderstone.com/ Linkedin: http://www.linkedin.com/in/seanharries On 17 November 2014 18:14, Jarl Grøneng jarl.gron...@gmail.commailto: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.commailto: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
Re: Ticket Data Migration from 7.5 to 8.1
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
Re: Ticket Data Migration from 7.5 to 8.1
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
Re: Ticket Data Migration from 7.5 to 8.1
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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Ticket Data Migration from 7.5 to 8.1
Hi, In most cases I actually do not do it in in batches. But using the maxerrorsperform=100 or similar is good practice. Because of the Delta Data Migration capabilities, data that succeeded will not be copied the next time you run it. Some qualifications will actually disable the Delta Data Migration capabilities of RRR|Chive. The same query will be cone on both servers, and if you use something like 'Last Modified By' 2014-01-01, you might get into trouble. So the main strategy should be to move all data. splitsearch = 1 qual = transfertype = SYNCTOTARGET maxerrorsperform = 100 Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Yes, rrrChive will do this just fine. I suggest you move the data in batches rather than all at once. rrrChive allows qualifications, so you can select the oldest first, in groups of less than 100k records each. Starting with the oldest records will reveal problems early in the process; for example, trying to bring in records with out of bounds values that WERE valid before changes. rrrChive also lets you set a maximum # of errors that will stop the process. By setting this to 10, you don't have the same error for 100k records and nothing copied. It's a very powerful utility, so RTFM, as the documentation is clear and comprehensive. During the week leading up to the final cut-over, run rrChive every night; the last update is only one day's activity, which will go very quickly. Joel Joel Senderjdsen...@earthlink.net310.829.5552 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Saturday, November 15, 2014 8:57 AM To: arslist@ARSLIST.ORG Subject: Re: Ticket Data Migration from 7.5 to 8.1 I know others are going to say the same Go get RRR|Chive from http://www.rrr.se Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kiran Patil Sent: Saturday, November 15, 2014 1:11 AM To: arslist@ARSLIST.ORG Subject: Ticket Data Migration from 7.5 to 8.1 ** 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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
Re: Ticket Data Migration from 7.5 to 8.1
Although DDM was not designed to do the bulk data load you want it can possible be used to do this. BMC will not officially support it. I anticipate the you will get other recommendations. -Original Message- From: Kiran Patil kiranpatil@gmail.com To: arslist arslist@ARSLIST.ORG Sent: Sat, Nov 15, 2014 2:10 am Subject: Ticket Data Migration from 7.5 to 8.1 ** 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Ticket Data Migration from 7.5 to 8.1
I know others are going to say the same… Go get RRR|Chive from http://www.rrr.se Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kiran Patil Sent: Saturday, November 15, 2014 1:11 AM To: arslist@ARSLIST.ORG Subject: Ticket Data Migration from 7.5 to 8.1 ** 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Ticket Data Migration from 7.5 to 8.1
Yes, rrrChive will do this just fine. I suggest you move the data in batches rather than all at once. rrrChive allows qualifications, so you can select the oldest first, in groups of less than 100k records each. Starting with the oldest records will reveal problems early in the process; for example, trying to bring in records with out of bounds values that WERE valid before changes. rrrChive also lets you set a maximum # of errors that will stop the process. By setting this to 10, you don't have the same error for 100k records and nothing copied. It's a very powerful utility, so RTFM, as the documentation is clear and comprehensive. During the week leading up to the final cut-over, run rrChive every night; the last update is only one day's activity, which will go very quickly. Joel Joel Senderjdsen...@earthlink.net310.829.5552 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Saturday, November 15, 2014 8:57 AM To: arslist@ARSLIST.ORG Subject: Re: Ticket Data Migration from 7.5 to 8.1 I know others are going to say the same Go get RRR|Chive from http://www.rrr.se Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kiran Patil Sent: Saturday, November 15, 2014 1:11 AM To: arslist@ARSLIST.ORG Subject: Ticket Data Migration from 7.5 to 8.1 ** 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
