switch version ucm 7.1.3(4) back to 7.1.3(2) test

Answered Question
Aug 17th, 2010

Hello,

I'm testing to switch version back to a lower version. I only have one ucm server. The problem is that the configuration that i made on the new version are not seen in the old version. For example i configured a phone with lines. When ik switch back to the older version the phone is not seen in the configuration of the ucm. I don't understand why. BTW when i switch back to the newer version the phone is seen agian with the lines.

Can anybody explain this to me and how to solve this?

Greetz,

Tinus.

I have this problem too.
0 votes
Correct Answer by Aaron Harrison about 6 years 3 months ago

Hi

That is working as designed.

Basically when you upgrade, the system installs the new OS/APps to the inactive partition, and then migrates your data accross. When you choose to reboot to the new version, only user-facing configurables (such as current call forward settings etc) are migrated accross.

When you switch back, you also go back to the original version of the DB; the new version's database is not migrated back.

There are probably lots of reasons for this - If new config changes are pushed back to the old DB, then rolling back a failed upgrade would not be 'clean' and would require further manual regression work. Also newer config elements may not be supported by the old version (e.g. new phone types or features), so lots of extra work for Cisco to map the data back and potential loss of config...

The idea is to quickly get you back to where you where before  the upgrade as a quick rollback, not to allow you to randomly switch versions at leisure weeks later if something doesn't seem right...

Regards

Aaron

Please rate helpful posts...

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Aaron Harrison Tue, 08/17/2010 - 01:20

Hi

That is working as designed.

Basically when you upgrade, the system installs the new OS/APps to the inactive partition, and then migrates your data accross. When you choose to reboot to the new version, only user-facing configurables (such as current call forward settings etc) are migrated accross.

When you switch back, you also go back to the original version of the DB; the new version's database is not migrated back.

There are probably lots of reasons for this - If new config changes are pushed back to the old DB, then rolling back a failed upgrade would not be 'clean' and would require further manual regression work. Also newer config elements may not be supported by the old version (e.g. new phone types or features), so lots of extra work for Cisco to map the data back and potential loss of config...

The idea is to quickly get you back to where you where before  the upgrade as a quick rollback, not to allow you to randomly switch versions at leisure weeks later if something doesn't seem right...

Regards

Aaron

Please rate helpful posts...

Actions

This Discussion