4 Replies Latest reply on Jan 15, 2016 9:50 AM by MRitte

    Complicated Move Strategy

    MRitte Apprentice

      I have a client who is buying his father's business.  They both run separate GoldMine systems.  However, the buyer's system database originally came from his father's.  So there will be many duplicates between the two.

       

      My first step is to get both systems upgraded to 2015.2 HF1. 

      Then I plan to copy the father's SQL database to the son's SQL server and add it to GoldMine.  I am thinking at this point that his employees will just have to jump from one to the other database for a period of time. 

      Eventually as time allows we will need a strategy to move/copy/merge the contact records from the Father's to the Son's database and eliminate the Father's database.

       

      I realize I need to find out what they want to do with attachments, templates, reports, etc.

       

      Has anyone ever done anything like this?  I have done plenty of moves from one server to another.  But nothing like this.

        • 1. Re: Complicated Move Strategy
          John Neighbors SSMMVPGroup

          I've done this a couple of times through the years.  You've simply got to be meticulous about every facet of GoldMine (from a data perspective), fleshing out the details.  A big help is if they can provide input as to what's truly important or not; otherwise, you might end up spending valuable and costly time on something that's not important or needed.

           

          Once they provide feedback, cut out all they deem non-important or not wanted.  THEN, grind through the rest accordingly.

           

          Most components can be fairly easily "merged" into a single system.  The challenge will be "similar" items that have been changed differently on the two systems (e.g. merge template by same name/filename, but changed differently, report by same name/filename, but changed differently, etc.).  Custom fields can prove a time consumer as well, depending on their realities.

           

          Wish there was a magic bullet, but it's all about the details. ;-)

          • 2. Re: Complicated Move Strategy
            PJohns Apprentice

            Here's an idea. I agree with John "A big help is if they can provide input as to what's truly important or not;" then depending on what you need rather than move and copy all the records you may consider using the GM+View to present information that exists in the fathers database.So you could leave the father's SQL database alone once on the sons SQL server and view information via the GM+View tab where duplicates exist. Do a compare of some simple data to show which live customer records are not duplicate and import light information in to the sons main database (Contact1 & Contact2). Over time use the Father's database as a leads database and copy move any records converted to prospects.

            Hope that helps.

            • 3. Re: Complicated Move Strategy
              Shaul.Bel Apprentice

              Beside the above said you should first compare the contact2 tables of the 2 databases of GM.

              If you find any missing field on one of them you should create it

              You also have to compare data type of the fields and their length.

              Check if they are using the fields for the same purpose.

               

              The second thing you should do is to place in all contact records of one of the database some data to know where that record came from.

              • 4. Re: Complicated Move Strategy
                MRitte Apprentice

                Just getting back to this.  I have never created a GM+View using SQL.  Do you have an example you can send to me?