pjohns
5th September 2012, 18:41
Hello,

I am looking to move our Baan environment to a new server, following the process below. Will this work with regards to licencing the new server?

1. Build new server with new hostname/IP address.
2. Using backup from existing server restore $BSE to new server.
3. Move server to isolated network and set hostname/IP address to be the same as existing server.
4. Run Baan licence validation process and send security code to Infor.
5. Enter new validation key in to new Baan. New Baan system will now be licenced and running in isolated network.
6. Remove existing Baan server from live network and replace with new Baan server.
7. Run another restore of $BSE for any changes that may have occurred during steps 2 and 5.
8. New server running in production network environment.

I think I'm correct in saying that the licencing only relies on the .brand file which is found in the root -'/' of the file system. So the fact I'm overwriting the $BSE after the system has been branded shouldn't matter.

Any comments appreciated.

Thanks

PJ

Han Brinkman
5th September 2012, 22:11
PJ,

Depends, are you migration from the same platform?

We migrate normally to the new platform, validate it and let users test it. After approval we copy the data once again, not the bse.

Using the latest portingset 8.x you need to move to SLM. This requires some tools update (if your not uptodate) but has the advantage that you can use a 64 bits portingset meaning you don't have to use a 32 bit client for oracle. (according to your profile you use redhat, I migrated during the weekend a similair system)

So it depends on what you want to achieve....

Regards,

pjohns
6th September 2012, 11:25
Hello Han,

We are migrating to the same platform, Red Hat 5.

We do not use SLM in our production environment yet so will be using the 'old' licence dameon.We'll continue to use the 32bit Oracle client.

How do you copy the data? We take an offline backup of the existing server and then restore BSE along with the Oracle application and data directories.

I hear what you're saying about not copying the BSE a second time. Which I suppose we could get away with as nothing changes in the application between testing and go-live.

Regards

Han Brinkman
6th September 2012, 20:28
If you stay on the same platform you can easily clone your database. The easiest is to clone it offline.

Just install the latest oracle software on your new server. Shutdown baan and oracle on your current server. Copy all data but redologs and controlfiles. Before you have to run the 'backup controlfile to trace', that generates a sql script which you can use to recreate your instance on the new server. After it run's you have to follow the normal upgrade steps as described in the oracle documentation.

Use the old license file to login in to the new server first. After you logged in you change the license6.1 file to point to your new server and run the print system configuration supplying infor the data for which they can create a new key. Another option is to run the session 'patch objects after system crash' which should give you access for30? days and than follow the normal procedure.

Mind your database definitions, make sure tabledef and the database definitions match!

After testing you can clone your instance again, but only if you didn't change the software in the meantime.
Before cloning make a note of the license key so you can change them afterwards in the ttiex table.

Why do you stick with redhat5? We do support redhat6 in the meantime.
Since your users have to test anyway I recommend to upgrade the OS and database as well.

If you only want to migrate your production data after testing (assuming you have a lot of test data) you could export/import a few companies as well. We do have some scripts that can export/import the tables parallel using all cpu's you have in your server to speed things up. What's the quickest depends on the amount of data.

Regards,