Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Cisco Employee

Migration question - old and new Unity in the same Exchange 5.5 environment

Customer is upgrading their Unity from an AV version 2.43. That box is old enough that all new s/w and h/w will be brought in. They have asked about phasing the old box out over time and my question stems from this: In an Exchange 5.5 environment, can they shrink/grow an old Unity to a new one over time with both the old and new Unity pointing to the same message store/hidden attributes for users? Any process recommendations to follow here if so (if delete a user from the old system before bringing up their new box, how to deal with hidden attributes already present, etc.) Or, do they need to cut the old box off and bring up the new one to enable a functional system? Other pieces I'm missing?

Cisco Employee

Re: Migration question - old and new Unity in the same Exchange

A Unity 4.0 (or 3.1 for that matter) can live in the same Exchange 5.5 environment as a 2.4 box (there is no 2.4.3… did you mean 2.3.4? We went from 2.4.0 to 2.4.5 to 2.4.6…).

While the 2.x system writes a bunch more data to the directory than 3.x/4.x systems do, they do both “agree” on the tags that means a subscriber is currently “owned” by another Unity box and will respect that. So if you deleted a user out of the 2.x system you could then import them into the 3.x/4.x system no problem.

This is a very awkward migration strategy, however, in that you will lose all the users greetings, voice name, mailbox settings and all that – further, and more problematic, the users on the 2.x system wont be able to easily message to users on the 3.x/4.x box and vice versa – 2.3 didn’t have networking at all.

If it were me, I’d install a clean 3.x/4.x system into the environment and do a fullDBExport of the 2.x system and import it all in one shot – this is going to be _much_ cleaner and easier for everyone involve than doing a “slow bleed” migration across systems.