Hi !
Any one tried to migrate several instances of CME to one ?
At my company we have three Config environments that we want to migrate to one.
Any one tried the ConfigImportWizard ?
(List price from Genesys €25,000)
Or has any one done this on their one (NOT MANUAL CONFIG).
Reagards
Mikael Jansson
Tried to use EURO sign meant 25,000 EURO.
Mikael
I have used the CIW and it is great for adding lists of agents and skills. But have not tried moving 1 CME into another with it.
In theory if you move all the objects in the first CME into folders, then import the second CME put these into new folders, and then import the third CME you should have what you want.
It should work but I would build a test environment before I tried it on on a live system.
Hi !
Thanks för the resonse.
What type of “list” did you import, was it a CME export to XML ?
/ Mikael
I used it to import a xml file that was created from an excel spreadsheet.
Our customer was able to supply a list of all their agents (about 20000) and I used the CIW to import them about 1000 at a time, saving weeks of typing.
Guess it saves a “little” time 
Thanks for the input.
/ Mikael
( We don’t have that big environments, we have a total of 2500 agents so the price for the CIW is quite high for us.)
You can also get it to output the contents of yuor CME into a SQL Script ready to populate you new CME. If you have, or have access to, Oracle SQL skills you could maipulate the outputs of your 2 environments into one dump.
Not an easy task. Chances are that different objects in different configuration databases have the same DBID.
Probably the importing can be done, but will be a challenge keeping the integrity of the data.
At the very end, maybe if the configuration is not huge, typing is the best bet.
For applications objects, you can always export the Options to an cfg file and reimport them in another configuration server. For example:
you want transfer TServerA from CME A to CME_B
just create a new CME_B TServerA application object. Update host and startup info.
On CME_A export TServerA options to a file and import that file on CME_B
The process is kind of tedious, but probably will be faster that trying to do a big bang transfer.
For agents and DNs usually they come in ranges, so you can create them pretty quickly
and then hire two or three friends to create places and persons objects.
these are my two cents. If somebody comes up with solution I would love to know about it.
It really depends on your configuration.
ImportWizard would be probably worth a try if you have three billion agents to import. Otherwise, considering that you will have to check the whole configuration anyway, recreating it in one CME would be much much easier.
Here is what I would do:
Recreate everything but People
Export People from CME A into CSV
Write a simple script to populate people into CME C, keeping in mind dbid needs to be increased and the next available dbid needs to be written in cfg_maxXXX (I forgot the real name…)
You can also do it in a few days by looking at their cfgDB, and realizing that:
dbid has to be increased for every object
max dbid is stored in cfg_maxXXXX.
A really simple hack would be to just add 5000 to all cfgid and dbids for site A and 8000 to SiteB and then import all of it into SiteC and then modify cfg_max to reflect the next dbid you want Genesys to use when a new object is created.
It is not just that but it is not that hard either.
I am sure Genesys is not going to be very happy if you do it, so if you can afford their tool go buy it…
I wonder if any of us can write an Import/Export Tool of our own…
Vic
IMHO, I think that when you import Persons you need to recreate the db links to have the right skills and agent_id assigned, groups, etc linked to the right Person.
Keeping that data integrity is critical and there are few tables in addition to CFG_PERSONS involved. After you import CFG_PERSONS you need to touch CFG_LOGIN_INFO, CFG_SKILL_LEVEL and the thing start to get pretty uggly if there groups and default places defined.
Really I think that host and applications objects can be easily exported and imported again changing just the dbid. (still would recreate the connections manually).
Everything else, unless there is a good understanding of the database schema and somebody with good SQL scripts, is going to be too risky to import just like that and the chances to screw up everything are pretty high.