Migration Precheck fails due to Restore from different IP address

[kwbMitel]

I've inherited a 8 element system that is curently running MCD 4.0 SP4

We're looking to Upgrade to 5 over the weekend and I've run into a little problem.

It appears that the previous owner took some shortcuts when deploying the systems and now I have to fix it.

I'm hoping I can fix the error below with a simple backup and restore

Thoughts?

MIGRATION PRECHECK

Checking for network element and cluster element database consistency.
A database inconsistency was found.
This database inconsistency is a result of restoring a database backup taken from a network element with a different IP address than that of the local network element, likely before upgrading to 10.0.
DO NOT MIGRATE THIS DATABASE.
Instead, you should restore the database to a network element with an IP address that matches the one from the backup, and then run the MIGRATION PRECHECK command again.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[LoopyLou]

This was always one of the things you had to watch in migrating from say an MX controller to a MXe ( i.e to be able to move past Release 9 ). The thing you had to do is if you took the database from the MX you had to setup the MXe with the exact same IP addressing that was on the MX. Otherwise although it appeared to take and convert the MX database it would only do so with issues. I think it is saying that you have to find the original datasave and restore it on your controller with the same IP addressing as the datasave. Good luck right. Wonder if you could blow away the IP information in your database,save it and then restore it to fix. Otherwise don't think I can help.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[kwbMitel]

Loopylou, Your answer is pretty much what I was afraid of.

What actually happened here is they had a bunch of SX200's in other buildings

The 200's were replaced with 3300 CX-II's

The %$#@*&^% that set them up, took shortcuts by uploading 1 database to several systems

This took place in 2009. Going back is not an option.

God help me if I have to format and hand punch.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[LoopyLou]

Guess you can try it. Don't think the database is repairable.

Otherwise if you have to reprogram them what about export export export and using the configuration wizard to reprogram the system using the exported files. Might speed it up.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[kwbMitel]

I'm quite proficient with export/import but I really don't like the idea.

Add to that, I'm contracted out to do this job so billable hours are a major factor.

Talking to Mitel as I write this. I'll update soon (tomorrow)

**********************************************
What's most important is that you realise ... There is no spoon.