MX to MXe Migration question

[MitelInMyBlood]

Migration guidelines notwithstanding, is it possible to migrate the database to a new platform having a different IP address than the source machine?

We've been asked to move the voice systems over to another subnet and I thought this might be an opportunity to start...or not.. Some guidance needed here. Thanks.

 

[kwbMitel]

Cluster programming, Networking, and anything else IP related will possibly corrupt or disappear altogether.

Learned the hard way!

Migrate the DB according to the DOC's

Set the IP's the Same

Change the IP Afterwards.



*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[tlpeter]

Or export the most important things like users and devices
ipsettings ars cos cor etc etc

The only thing you can not do easely this way is groups
I once did it this way and strugled there
I needed to manualy enter the groups in to the system to import all settings

ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[MitelInMyBlood]

Thanks!!

We'll stay with the current IP address, name etc.

OK so dumb novice question time (this will be my first MX/MXe migration) How can you have the identical IP address active on the network at the same time? You can't, so what do you do?

My plan was to stick a dummy IP address on the new box, go get the licenses, but then what? My goal here is to minimize the customer's down time, but once I set the IP address of the new box same as his old box then his old box has to come down **AND** we have to wait for the ARP cache to clear before I can connect the new box, install s/w, restore DB, etc. Apparently I'm missing something really obvious as I see this taking a good hour-plus of outage time to go through it.

How about this, dummy IP address to start with, install S/W (9.0 UR2), pull the licenses down from AMC, then pull the IP connection from the running box (customer goes down), change IP address on the new box, clear the ARP cache, reboot the new box and restore the database? Still seems like a fat outage. I was thinking this should only be like a 15-minute hit.

What are the rest of you doing?

Thanks

 

[kwbMitel]

Why do they both need to be connected at the same time?

-Fully prepare new controller - but not connected to network
-Backup from original
- Restore to new controller
- Re-program analog devices as per Migration DOC.
- Disconnect old Controller
- Connect new controller
- Bounce POE for all sets

Not even down for 15 minutes, more like 2.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[MitelInMyBlood]

OK - I think I get the picture. Backup the existing controller to my laptop rather than to the network drive that OPS uses. Ordinarily the backup DB is on the network drive. I'll get it off the network drive and put it on the laptop

I've got to have the new controller set to the IP address of the existing controller before I do the restore, right?

As for analogs, there are none actually "on" the old controller, rather they (and the PRIs) are on a per node and DSU node connected via fiber. In my reading I think these will restore OK, correct?

The outage will still be (minimum) for as long as it takes the MAC address of the old controller to clear out of the ARP cache, right? Also the TDM pers are going to reload as soon as I move the fibers and the TDMs don't exactly come bouncing right back, more like 15 mins as I recall.

At what point do I change the IP address on the new controller? It obviously cannot be on the network while the old one is still connected, yet I've got to get it on the Internet to get to the AMC to get the licenses pulled down. I prolly need to call them first. I think I had it right the first time, let the MXe get his licenses using another IP address, then change it

I feel like such a complete noob here, but as stated, this is my first one to migrate and the PBX is in a high profile location acting as a tandem between a 2K, a Cisco CM and some 30 other MXe's. I can't afford an awwschitte the first time out. ;-)

 

[Lundah]

Here's how I'd do it:

Pre-cutover (at least 1 day before cutover):
-Assign a temp. address to the new box
-Download licenses to new box
-After it's licensed, pull new box from network, change IP address, load database just to be sure it will take.

Cutover:
-Backup old box to PC & restore to new box (still off the network)
-Pull MX from network, wait for ARP cache (can this be cleared manually?)
-Connect MXe to network and test

 

[MitelInMyBlood]

Lundah.... That's exactly how I did it earlier today. I'm down to the cutover step(s) Went lots smoother than I expected, esp. the AMC piece.

Planning the mirror the drives as a final step just before cutover.

Yes, there's a command to flush the ARP cache, but the network guy told me this AM that it automatically clears itself after 5 minutes so I shouldn't have to worry about it.

Network cables & fiber is all custom, cut-to-length with very little slack (grrr..), so there should be enough downtime making the physical switcheroo to take care of the ARP cache. Also knowing that there's some per nodes and a DSU node which themselves will take several minutes to reload takes the pressure off. In the final analysis however long it takes will be however long it takes.

Thanks again