One point of clarification... I perform the object type by object type migration process when moving a new app or a large number of changes to an environment. For smaller (update) changes (a few dozen of objects) I'll migrate everything at the same time.
Jason On Mon, Feb 13, 2017 at 10:27 PM, Jason Miller <jason.mil...@gmail.com> wrote: > To answer your original question, I use Migrator for 99% of the objects I > move between environments. > > Now I don't let it fly full-auto with the default config, that is just > reckless. I use Migrator along with the tracking form/process I detailed > here: https://communities.bmc.com/message/555604#555604. > > First I set all Migrator "Required Objects" to no. I also run migrator in > scripting mode. I then have a flow I usually flow where I run a difference > report of forms, add the forms to the script as appropriate (while > reviewing the differences), and migrate. Then I refresh the difference > report to make sure the results are what I expect. I then do the same thing > with Active Links. Then with Filter and keep repeating this process with > the different object types. > > The 1% that is left is usually renaming objects (I like to fix spelling > issues and rename objects that may have been originally given vague or > misleading names), creating/updating DB views for View Forms that will be > migrated, deleting objects, etc. > > Jason > > On Mon, Feb 13, 2017 at 5:19 AM, Brian Pancia <panc...@finityit.com> > wrote: > >> ** >> >> Misi, >> >> >> I've been playing around with your tools and as always they are pretty >> awesome. There's a new tool in ARS 9.1 called AR System Deployment >> Management that looks pretty promising. Messing around with Migrator was >> painful just like I remembered. It looks like the deployment tool will end >> up replacing Migrator. Another toy to add to the tool box. I'm sure there >> are a few kinks that need to be worked out of the deployment tool, but I'll >> give it a go to see how it works. I'm curious to see anyone else's >> experience with the deployment tool. >> >> >> Thanks again, >> >> >> Brian >> >> >> >> >> ------------------------------ >> *From:* Brian Pancia >> *Sent:* Friday, February 10, 2017 8:14 AM >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Migrator Tool >> >> >> Awesome. New toys to play with. I'll have to play with different >> scenarios depending on the source and destination servers. I'm thinking >> monthly syncs to dev and weekly syncs to test for code. I may do weekly >> data syncs to both environments. In theory Prod and Test should be locked >> down, preventing development directly from there, but that's a different >> beast to tackle. I guess RRRDefDiff will be a good way for me to tell if >> updates are being made to Prod or Test without going through Dev>Test>Prod >> sequence. Batching that process out may be interesting to see if >> developers aren't following the proper process. For a COOP environment I'm >> thinking using SQL replication is probably the best bet. With replication >> I can do near real time updates. >> >> Brian >> ------------------------------ >> *From:* Action Request System discussion list(ARSList) < >> arslist@ARSLIST.ORG> on behalf of Misi Mladoniczky <m...@rrr.se> >> *Sent:* Thursday, February 9, 2017 1:37 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Migrator Tool >> >> ** >> Hi, >> >> Why not try a combination of RRR|ExportDef, RRR|DefDiff, RRR|ImportDef >> and RRR|DeleteObject. >> >> The important one is RRR|DefDiff, mening that you can use other tools to >> export/import definitions and delete surplus objects. >> >> https://rrr.se/cgi/tools/main?tool=rrrDefDiff >> >> RRR|DefDiff <https://rrr.se/cgi/tools/main?tool=rrrDefDiff> >> rrr.se >> RRR|DefDiff updated 2015-06-16 Finds differences between two def-files >> >> >> >> https://rrr.se/cgi/tools/main?tool=rrrExportDef >> >> RRR|ExportDef <https://rrr.se/cgi/tools/main?tool=rrrExportDef> >> rrr.se >> RRR|ExportDef updated 2012-11-23 Exports definition files from your server >> >> >> >> https://rrr.se/cgi/tools/main?tool=rrrImportDef >> >> RRR|ImportDef <https://rrr.se/cgi/tools/main?tool=rrrImportDef> >> rrr.se >> usage: rrrimportdef [ -l error.log ] [ -e error.def ] [ -verbose ] [ >> -silent ] server tcpport user password import.def usage: rrrimportdef -help >> >> >> >> https://rrr.se/cgi/tools/main?tool=rrrDeleteObject >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) >> >> RRR|Home <http://www.rrr.se/> >> www.rrr.se >> RRR|Log Fix specific performance problems or work proactively with >> performance by using RRR|Log. It will help you make sense of the >> information in the Remedy log ... >> >> >> >> >> 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 >> >> RRR|Home <http://rrr.se/> >> rrr.se >> RRR|Log Fix specific performance problems or work proactively with >> performance by using RRR|Log. It will help you make sense of the >> information in the Remedy log ... >> >> >> >> >> >> February 9, 2017 5:52 PM, "Brian Pancia" <panc...@finityit.com >> <%22brian%20pancia%22%20%3cpanc...@finityit.com%3E>> wrote: >> >> I'm blowing off the dust on BMC Migrator. It has been years since I've >> messed with it. I've used it in the past to migrate small amounts of code >> from dev to test to production. What I'm looking at now is using it as a >> sync tool between the environments for code only. I've usually just done a >> database backup and restore in the past and for small code migrations I >> just export/import .def files. There are definitely pros/cons to all these >> methods. My plan now is to use RRRChive to migrate data updates and BMC >> Migrator to do code migration. This will give me much more control then a >> simple database backup and restore. Is anyone currently taking this >> approach between dev/test/prod. We're using MS SQL 2012 on the backend, >> which I'll use database replication between prod and coop. >> >> Brian >> DISCLAIMER: The information contained in this e-mail and its attachments >> contain confidential information belonging to the sender, which is legally >> privileged. The information is intended only for the use of the >> recipient(s) named above. If you are not the intended recipient, you are >> notified that any disclosure, copying, distribution or action in reliance >> upon the contents of the information transmitted is strictly prohibited. If >> you have received this information in error, please delete it immediately. >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> DISCLAIMER: The information contained in this e-mail and its attachments >> contain confidential information belonging to the sender, which is legally >> privileged. The information is intended only for the use of the >> recipient(s) named above. If you are not the intended recipient, you are >> notified that any disclosure, copying, distribution or action in reliance >> upon the contents of the information transmitted is strictly prohibited. If >> you have received this information in error, please delete it immediately. >> _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"
