In-Place Upgrade NetWare to Open Enterprise Server

By: mweiss2

October 3, 2011 11:03 am





Currently, Novell doesn’t support an in-place upgrade from NetWare to OES. This has prevented some customers from upgrading to OES.
To address this shortcoming, Novell Consulting is investigating a procedure that allows customers to perform an in-place upgrade when certain prerequisites are met and address the following needs.

  • Be running a supported platform before the end of Extended Support for NetWare 6.5
  • Avoid transferring data from old to new hardware
  • Avoid the long downtime that is required for a migration
  • Avoid purchasing new hardware for migration

The attached document presents a technical overview of a type of in-place upgrade. The solution presented in this document allows customers to

  • Use the existing server when it meets the prerequisites, simply replacing the OS.
  • Upgrade the platform without touching existing data. In fact, users can simply reconnect afterward.

In addition, this process requires only a short downtime per server.

Attached to this article you will find the following files

  • The detailed description of this solution
  • A set of tools and scripts to start with
  • A link to some prepared appliances to have a quick start

The solution itself consists of 4 major steps


  • Build Upgrade-DVD with appliances build in SUSE Studio
  • Backup Identity (run mig-pre.ncf on Upgrade-DVD)
  • Replace OS (boot Upgrade-DVD with
  • Restore Identity (

Depending of the scope of your upgrade and the selected option the whole process takes from 30 minute up to 1 1/2 hour.

Detailed instructions and example-scripts are attached to this article.
Example appliances for this method can be found at

Feedback is welcome!



0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Open Enterprise Server on SLES, Technical Solutions

Disclaimer: As with everything else in the SUSE Blog, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.


  1. By:jzitnik

    The documentation is to upgrade to SLES 11. Can this same process be used to upgrade to SLES10 SP3? We have a new piece of software coming on board that supports iPrint, but only on SLES 10.

  2. By:pjohanon

    This sounds nice on paper, but it is dangerous. My philosophy has always been to have a way to return to the old server if something goes wrong. If you have a separate piece of hardware, and the installation fails, you can go home and try it again another day. If you are doing an in-place upgrade, and the installation fails, you have an all night frantic panic session restoring the OS, and restoring the data from backup. Money tight? Buy a used piece of hardware, and do a migration. Contented users and piece of mind is very important.

  3. By:smflood

    If you read the attached PDF (page 4 – PDF page 8) you’ll note that Martin tested this with 64-bit OES2 SP3 on SLES10 SP4 (as well as OES11 beta on SLES11 SP1).


  4. By:chapindad

    You are assuming that everyone still uses their local disks for storage. I boot from a Compellent SAN so I can make a replay before I try the in place upgrade and if it goes bad then I just roll back to my replay and reboot the server. Do a search for Davenport Group, my Compellent Business partner, and they will explain it to you or put you in contact with me.

  5. By:mweiss2

    The outlined method was tested with SLES 10 SP4 (together with OES 2 SP3).
    BUT – SLES 10 SP3 is not supported with Studio 1.2 anymore so you can not build that image in Studio – but if you build your own image it might work with some customization.

  6. By:mweiss2

    You are right – moving to a new hardware should be the better option. However – this is not always possible or too much effort (ex. if you have >600 servers distributed worldwide ;-)).

    This method has some risk – and due to that it must be customized and tested for the environment where it should be used and a backup is required in any case.

    Keep in mind, that this method also allows you to have some sort of a failback. If you copy the SYS volume to an other pool before the SYS pool gets deleted – a failback to NetWare is still possible.