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"
