Hi This is a DDM instruction file, and you can see that the field mapping using an import-tool format.
<data-instructions> <data enabled="true" source-form="TMS:Task" destination-form="TMS:Task" type="data" mode="search" merge-option="update" ignore-required-fields="true" ignore-pattern-matching="true" count="0" disable-related-workflow="true"> <qualification>PASS_QUALIFICATION</qualification> <unique-fields> <field id="179"/> </unique-fields> <ports enabled="true" list="LIST_PORT" fast="FAST_PORT"/> <field-mappings enabled="true" file="TMS_Task_PD8303_Mapping.arm" type="2"/> </data> </data-instructions> Regards, Jarl 2017-04-20 14:48 GMT+02:00 Misi Mladoniczky <m...@rrr.se>: > ** > Hi, > > So RRR|Chive works in a similar way, where matching ids are the default, > regardless if it is a custom field or not. Fields can then be > mapped/skipped specifically. > > It sounds like a simple thing to generate rrrchive-config-files based on > the mapping-files from DDM!? Any chanse of supplying me with a few > DDM-config-files to allow me to check how much work it would take? > > 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 > > > April 20, 2017 1:49 PM, "JD Hood" <hood...@gmail.com > <%22jd%20hood%22%20%3chood...@gmail.com%3E>> wrote: > > ** > As for custom fields, the in the 7.x version, the default DDM mapping was > based on matching field IDs, unless a different mapping was specified. So > as long as custom fields had the same field ID between the systems, the > data would migrate correctly. > > So, with DDM migrating between two forms, it would map based on matching > field IDs for all fields that were not mapped specifically. So if you > looked at the mappings for the specifically mapped fields, it only listed > the odd-ball fields that needed to be mapped because their ID's differed > (presumably due to version changes). As long as custom fields had the same > field ID between the systems (or if you manually edited the DDM mapping to > include the custom fields if the ID's differed), the data would migrate > correctly. > Biggest issue I had with DDM is that it was slow, Slow, SLOOOOOOOW. > Thanks, > -JDHood > On Thu, Apr 20, 2017 at 6:19 AM, Vinod Gaidhani <vinod.gaidh...@gmail.com> > wrote: > > ** > Thanks Misi, seems to be good and overcomes shortcomings of DDM. > > Vinod. > > On 20-Apr-2017, at 2:30 PM, Misi Mladoniczky <m...@rrr.se> wrote: > > ** > Hi, > > One big difference between DDM and RRR|Chive is that DDM just finds all > records after the date/time you specify and transfer these records. > > RRR|Chive will pull all recordids and modify-dates from both system and > then do transfer/delete as appropriate. No need to specify a date. > > Because of this it is easy to use to restore a system after, for example, > testing. > > I have been playing with the idea of using the DDM mapping files in > RRR|Chive, but have not come around to doing this. So you are pretty much > on your own and need to do the mapping yourself. > > I am not 100% sure about this, but I think that DDM will not copy data on > custom fields you have added yourself automatically. > > I have another tool I like to use when planning migrations to new > application versions, and this is RRR|DefFieldDiff that will give you an > excel sheet of all changed data fields. This makes it easy to find > differences and plan your data massaging. > > 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 > > > April 19, 2017 2:39 PM, "Murnane, Phil" <phil.murn...@windward.com > <%22Murnane,%20phil%22%20%3cphil.murn...@windward.com%3E>> wrote: > > We've used DDM and RRR|Chive successfully on various projects. Misi's tool > is scriptable and very fast compared to DDM. DDM can schedule code and data > migrations. Generally both require the Last-Modified date/time field to be > accurate. Overall, I'd personally recommend RRR|Chive. > > > HTH, > > --Phil > ------------------------------ > *From:* Action Request System discussion list(ARSList) < > arslist@ARSLIST.ORG> on behalf of Nicosia, Ryan J. CTR USSOCOM HQ < > ryan.nicosia....@socom.mil> > *Sent:* Wednesday, April 19, 2017 8:14 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: [Non-DoD Source] Re: need input about data migration after > Upgrade > I have to disagree. We used DDM with great success but it does require > admin freeze on all deletion activities of your production environment. > That said, there are ways to get around that as well but purging the form > in question on your target server and telling DDM to just pull everything > over. > > Once you get to the point where you are running DDM every few days, the > errors are easy to identify and clean up and you can re-run a specific > package as needed. > > Ryan > > -----Original Message----- > From: Action Request System discussion list(ARSList) [ > mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] On Behalf Of Mohamed > Kamruzzaman > Sent: Wednesday, April 19, 2017 5:50 AM > To: arslist@ARSLIST.ORG > Subject: [Non-DoD Source] Re: need input about data migration after Upgrade > > Hi Amit, > > Agree with Vinod, you may want to look at alternate solution considering > you are looking at migrating and cleaning your data. You will want to > migrate over foundation, configuration and transactional data onto ITSM 9.x > . This is an ideal time to clean up data, remapping Prod cats and Op Cats > etc. and potentially archive some of the tickets that you no longer need. > > We use our Customer Move Tool (more info [CAUTION] > http://www.alderstone.com/cmt) for the migration from previous ITSM > versions to the latest, as we can migrate all modules data or a reduced set > (including transformation and cleaning of data), depending on your > requirements. In general we've been able to move entire data set within a > day ensuring a smooth migration. Please let me know if you would like to > talk about this in more detail or have any specific questions. > > Regards, > Mohamed > > Mohamed Kamruzzaman. Alderstone.com +962776723269 | > mohamed.kamruzza...@alderstone.com | Skype: mkamruzzaman | LinkedIn: > Mohamed-Kamruzzaman > > ____________________________________________________________ > ___________________ > UNSUBSCRIBE or access ARSlist Archives at [CAUTION] 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" > _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_ > > _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"