Advise for swingbox MDB migration

[Jacques Geldenhuys]

Hi All

 

I'll be using the swing box approach to migrate our 14.1 environment to 17.x

 

Seeing that I will be making a backup of my production MDB to perform the swing box method on and by the time I go live with the new version it is 3 months later, how or what can I do to migrate or move the 3 months worth of data from current production (14.1) to the migrated 17.x MDB since I made the backup for the swing box approach.

 

Is it a case of moving predefined data from selected tables to the new migrated environment?, will MDB versions be an issue?, it will need to include scoreboard tables, call_req key table to continue with the next reference number, animator, change and ... or maybe it is better to just exclude key tables that you don't want to be overwritten, like 'al_cdb_componentinstallstate' and 'al_cdb_configurationparameters'

 

Does anybody have any advice on the best way to bring the migrated environment up to date with data in the shortish amount of time

 

Hope my question makes sense.

 

Kind Regards

Jacques

 

[Kyle_R]

Hello Jacques,

 

Don't even think about partial moves of the database, and nor about moving data between versions directly.

The upgrade process adds in extra tables and fields, and updates links.

 

Your main choice up front will be:

• "Upgrade in place on the production system"
  OR
• "Upgrade a development system with a current copy of production data to production. Then switch Dev. to Prod."

 

Either requires that you have run through an upgrade on the test systems so that you have a bombproof run sheet.

 

Both require that you halt the production system for the number of hours it takes to get the systems up.

 

The advantage of the first method is that you avoid moving data back and forth off the production hardware.

If something goes wrong, you need to restore the production environment back to the way it was.

 

The advantage of the second method is that the production system is left intact.

If something goes wrong, you just turn back on the old production system.

And you have as many tries as you want to get a successful upgrade.

 

I'd recommend the second method, even though it requires an extra configuration to change from Dev. hostname/IP to Production.

 

So the overall process may look like this:

 

1) Tidy up and split out your system so that the bear minimum of data needs to be copied in later steps.

Move Attachments to their own Repository server. Archive and Purge as much data as possible, including session_log and not_log_header data. Move the Archives out of the SDM structure. Move anything not SDM out of the SDM structure. (SDM backups in particular end up in this folder for some reason.)

 

2) Work out the very quickest way that you can set up a Development system on ITSM 14.1.

Typically, this would be "Set it up on a VMWare environment, so you can restore a snapshot" - which is about a minute.

 

3) Add to this snapshot all of the "non-changing" data from the production environment. This would be things like customisation files (site/mods), configuration settings (NX.env). This would be another snapshot point. Then call a halt to any changes to these "static" parts. (No more customisations, no more patches, for example.)

 

4) Work out the quickest way that you can transfer data using the Swing Box method. 

Ideally you will have this down to a batch file. 

 

5) Have backup (preferably VMWare or equivalent) of the key servers, ready to restore if needed.

 

6) Go time! Stop Dev. and Prod. servers. Implement (4). Check that all data is over.

This will include the database, Attachments (If you ignored the advice to move them off server) and anything outside of the "static" section taken earlier.

 

7) Upgrade the Dev. system from 14.1 to 17.1. Check that it all works.

 

8) Switch Dev. over to be the new Production system. Typically this involves redoing the host name/ip address and re-running configure. (Or if you did this all on Prod, you can skip this part - just bring it up.)

 

 

So in short, you'll be doing the whole upgrade again. Your aim is to make it as quick as possible. The three months you mentioned that you spend in preparation is all about making sure that the upgrade works when it occurs. The actual upgrade itself should only be as long as it takes for the batch jobs to copy files, move the database, upgrade and run configuration. That is, a few hours best case.

 

 

 

Thanks, Kyle_R.

[Jacques Geldenhuys]

Hi Kyle

 

Thank you very much for your detailed answer and input, your process points help a lot.

 

Thank you, much appreciated

 

Kind Regards

Jacques