So what is the best way to go Migration or Upgrade in place?
1 Like
We attempted an upgrade in place from BI4.2sp8 to BI4.3sp1 patch 8. When we got to our distributed environment we started having services that wouldn’t update or be installed properly. We ended up abandoning the upgrade in place and are working on a migration to BI4.3sp2.
Thanks for that exactally what I am looking for. 
What do you mean by “distributed environment”? We are on BI 4.2 SP9 Patch 4 and would like to upgrade in place to BI 4.3 SPx probably within a year. Perhaps that is ill advised.
By distributed environment, I mean a horizontally scaled installation.
We have:
- 2 Nodes that run Web Intelligence Processing servers
- 2 Nodes that run Crystal Reports Processing servers
- 2 Nodes that run the Adaptive Job server and other services not directly related to WebI or Crystal processing.
- 2 Nodes that run CMS server
- 2 Nodes the run Tomcat for the web server
1 Like
We are the same less the Crystal Reports Processing. 2 application nodes, 2 webservers.
What do you run Tomcat on? Windows or Linux?
We run on Windows currently. All of our servers are on Windows. Our BI4.2 servers are on Windows Server 2016.
If your current system is not on the latest version of Windows Server, I highly recommend installing on new servers and then migrating. There’s a lot of configuration in 4.3 that is different from 4.2. So, if you have multiple servers and web servers to upgrade, you potentially will be down longer if you upgrade in place.
What I have done with my clients is set up and test the new production servers to make sure they’re working correctly ahead of the go-live date. Then I do the following for the migration - often starting 2 weeks or so in advance of go-live. Use the Promotion Management Wizard (PMW) for this process - it’s part of the server install. If you have multiple servers in the cluster, you can potentially use the PMW on multiple servers concurrently as long as there’s no overlap in the objects that each session is trying to migrate.
-
If you’re using third-party authentication, configure it on the new system but DO NOT add the user groups or set up auto-update. I will usually add a small group to test to make sure everything is connected right. Once I know that the user/group import is working, I delete the group and users so that I can start migration with a clean system. Keep the authentication auto-update turned off until after the final delta migration of users at go-live. This will prevent having duplicate users with different SI_CUID values.
-
Turn off the Job servers - we don’t want any production schedules to run here yet.
-
Import users and user groups without content. Include security with all imports.
-
Import universes, connections, calendars (if used), and events (if used).
-
If there are server groups in the old system, migrate them. You’ll have to reconfigure them after import so that they contain the new servers.
-
Import the contents of the public folders. Depending on the size of your system, you might have to break this down into multiple runs. Include instances but not dependencies because the dependencies should all have been imported already.
-
Import Favorites, User Categories (if used), and Public Categories (if used). Include instances but not dependencies.
-
Re-import and shortcuts, including the dependencies so that everything links up correctly.
DO NOT try to migrate your entire system in one shot - I have never been able to get this to work.
Depending on the size of your system, it may take several days to do this initial migration. If this is the case, you’ll want to do a delta migration (see below) to make sure you’ve caught everything that has changed since the migration started. Then you can compare the systems to see if anything is missing. I do the comparison a couple of ways:
-
I have written code using the Java SDK that will export lots of information from the CMS into .csv files. I run this against both the old and the new systems and compare based on the SI_CUID values of the objects (SI_ID will change in the migration!).
-
I’ve also done this by showing the CMC for each system in separate windows side-by-side so that I can compare objects and instance counts manually. This takes longer, but it’s not impossible.
-
There are third-party tools available from APOS and Wiisdom that can help with this as well.
If it’s going to be more than a couple of days before go-live, I recommend doing a delta migration every 2nd or 3rd day. This will also give you a feel for how long the final delta will take a go-live.
Delta Migration:
If you know there have been no changes to security, don’t include it in the delta migration.
-
In the Instance Manger of the new system, delete any schedules that would have run since the last migration.
-
Migrate users without content. This will migrate any user adds or updates that have happened since the most recent migration.
-
Migrate any universes, connections, calendars, and events that have changed since the last migration
-
Migrate Public Folders. Set the option to migrate everything since a specific date and use the date when you started the most recent migration. Include dependencies and instances so that you’ll get any new instances and they’ll correctly link up to their parent reports.
-
Migrate Favorites using the same instructions as Public Folders.
This should catch most, if not all, of the things that have been added or updated since the last migration. Again, you’ll want to verify what reports are in the folders to make sure that everything has updated. For the first delta you’ll want to verify everything again. Once you’re sure the delta worked correctly, you won’t have to verify everything again unless you want to. Also, be sure to check the migration logs if you see there are any errors during the migrations. The most frequent error I have seen in the logs occurs when the file that an object references is not found in the file store. If this is the case, there’s nothing you can do when the object is an instance. If the object is a report that has instances that are the same format as the report (as in not Excel, PDF, etc.), there’s a work-around for recovering it by copying the instance file from the output file store to the same file name and path as the missing report file in the input file store. Then edit the report and clear the data.
-Dell
7 Likes
I know this took you awhile and I appreciate all the details you provided. Another question since I am standing up a new environment.
What is the best database to use for the CMS? I am on Oracle and going to use 19c or better, but is there something faster? Better?
As long as the CMS database is located on the same subnet as the server(s), I don’t think it really matters which database you use.
-Dell
1 Like
Can we use the “Promotion Management Wizard” to migrate content from SAP BI 4.2 to SAP 4.3? I thought the Upgrade Management tool (UMT) should be used, but I can’t find the UMT after installing 4.3 on a new server.
Promotion Management Wizard is the tool to use, that’s what I have been finding out (see great explaination above).
I have it on my 4.2 servers, don’t know about 4.3 because I don’t have it installed yet.
1 Like
The recommendation for large migrations is not to use the Promotion Management Wizard (or graphical interface in the CMC.) There is a command line batch file, lcm_cli.bat. This is recommended for promoting large groups of objects or whole environments.
There is information on using this command line tool in the Administrator’s Guide. The Pattern Book on Life Cycle Management- Promotion Management is also a very good guide for how to configure and order your calls to the command line tool for migrations.
2 Likes
How about splitting servers between datacenters for high availability? I know the servers that are clustered are chatty but would this effect performance any?
And still have to split the APSs like in 4.2?
You don’t want to split your servers between data centers. The latency will play havoc with the communication. I did some testing with that and it was horrible.
The recommendation is to still split the APS. You can use the System Configuration Wizard for that. I always size our installations out for the maximum size and then shut down or delete the APS servers for the functionality we don’t currently use.
2 Likes
Absolutely! And you want to run multiple sets in the same order as I outlined in my post above about the PMW. My experience has been that trying to move everything from a large system in one go will run for 24 hours or more and then fail.
-Dell
We did migration for 4.2 to 4.3sp2 where they changed query panel for FHS and Excel that change is very buggy and ended up having to rebuild from scratch a number if report’s.
FHS? And what patch release are you using.
This is what is annoying, SAP is pushing all of us to 4.3 which isn’t that stable yet.
4.3 SP2 is so unstable. take SP1 lastest patch instead.
another question. I have all these AD groups because we user kerberos single signon.
Can this be pulled over to the 4.3 system or do I have to manually add them once I have the entire system Promoted?