When considering an upgrade or migration from an older version of SCSM to 2016 or 2019, there are 3 options. Each option has a different set of pros and cons, especially when it comes to Data Warehouse.
If you have a Data Warehouse configured and working in your environment, it is important to make some decisions about this data before you do any upgrade or migration.
Data Warehouse Considerations
How long do I need to report for?
When it comes to Data Warehouse records it is important to ask yourself, “how long do I need to report for?” If you need to report 3 years into the past, then you need to keep 3 years’ worth of data. If you have a company or government policy that states you must be able to report historically for 10 years, then you need to keep 10 years’ worth of data. Many customers don’t have a policy that sets a specific timeframe for historical reporting and when SCSM is first installed, many customers do not consider future historical reporting needs. If you have a policy that mandates a given time for reporting, then you must abide by that timeframe. If you don’t, consider what the business benefit is of this type of data before you store it for the next 10 years.
What is the business benefit for your reporting history?
Is reporting on ticket trends from the past 3 years going to help you plan for the future? I’d argue that technology moves so fast nowadays that what we were logging 3 years ago has no relevance on what we will be logging tomorrow. What actions will the business take if a historical report shows an increasing trend? Reports should have deliberate business actions associated to them. If reports are just written ad-hoc in an attempt to justify a business action, rather than the other way around, then the business will forever be fighting fires rather than solving long term trending issues.
What would be the business impact if all data was lost from the Data Warehouse? If the answer here is, “It would be a pain in the short term, but nothing critical,” or “there would be no impact what-so-ever,” then spending time, effort, and money retaining this data may not be the best use of precious resources.
I recommend thinking long and hard about how long you need the data before you spend a lot of time, effort and money in keeping historical data in your SCSM Data Warehouse.
What are my current database grooming settings?
Within SCSM you can setup how long Work Item data is stored in the transactional database (ServiceManager) before it is “Groomed” and is then only available via the Data Warehouse DB.
If you need to report for the previous 3 years and your grooming is set to 1 year, then you must retain access to the Data Warehouse data somehow as it is the only place it exists.
However, if the grooming settings are set to 3 years, then the data still exists in the ServiceManager database and will re-populate a fresh Data Warehouse if you started from fresh. This greatly reduces risk and time for upgrades as well as cost.
It is well worth checking out these settings before making a decision on your upgrade path.
Now that you have considered how important the Data Warehouse data is, there are three choices for upgrading\migrating SCSM.
3 Choices for Upgrading or Migration of SCSM
1) Side-by-Side Migration
This is the most “Risk-Free” of the migration options and gives you the most leverage to clean up any past mistakes and move forward with a clean environment.
In this scenario, you would first stand up a new SCSM environment (Management server, SQL server, etc.) and install a clean copy of SCSM.
You would then use the Cireson Lifecycle Management App (LMA) to migrate the settings and management packs from the production environment to the new environment.
Our Lifecycle Management app also identifies what management packs are not optimally written and can give you the option to split these out to make sure your Management Pack setup is running in best practice.
Once the settings have been moved over you can then run the CI and WI migration. This can be done in batches to prevent too much impact on production.
After running the LMA WI and CI migration once, you can then run the two systems side-by-side until you are ready for cutover.
Once you are ready to cutover, you run the LMA Ci and Wi migration once more (to capture all the changes from the last time you ran it) and shut down the old environment.
Data Warehouse
In a Side-by-Side migration, the Data Warehouse can’t just be copied over to a new Data Warehouse server as the server name must be identical to the original one it was created on to start with and must also be upgraded in the process so this makes this method impossible. However, it is possible to take the old Data Warehouse offline and re-write reports in the new SCSM environments to look at both the new Data Warehouse and the old Data Warehouse databases. This allows for the reporting ability to be maintained while having a totally new environment created.
- PRO’s
- No downtime for Analysts
- Ability to upgrade OS of SCSM Management Servers and SQL servers
- Ability to upgrade SQL version
- Ability to fix Management Pack issues rather than carrying them forward
- Time for testing without out-of-hours work
- CON’s
- New server infrastructure must be created for a while
- Data Warehouse connections are not available
2) Phased Upgrade
In a phased upgrade you install a new server with the OS you wish to run SCSM on in the future.
You then install SCSM on the new server, joining it as a second management server for the existing SCSM environment.
This upgrades the current SCSM environment and makes the old SCSM server redundant. The old SCSM server can then be turned off and the new Management Server can take over.
If you wanted to, you can then re-build the old SCSM server (with the same name etc.) and install a second SCSM Management Server.
Once installed and upgraded, it’s then possible to do an in-place upgrade of the SQL server’s OS and SQL versions.
Data Warehouse
In a phased upgrade the Data Warehouse does not change and the reporting services all remain intact. However, as the Management Packs change and get updated, there is always a risk that the ETL jobs have Sync issues that could take a very long time to remediate if possible at all.
- PRO’s
- Ability to upgrade OS of SCSM Management Servers and SQL servers
- Data Warehouse connections remain available
- CON’s
- Downtime for Analysts as the install occurs
- No ability to upgrade SQL version
- No ability to fix Management Pack issues rather than carrying them forward
- Migration and testing must be done using out-of-hours work
- New server infrastructure must be created and supported during the life of the project
- Risk of data warehouse sync failures
3) In-place Upgrade
An in-place upgrade is the most basic upgrade. In this scenario, SCSM 2019 is installed directly on to the existing SCSM Management servers without upgrading the OS or SQL versions.
Data Warehouse
Same as in a phased upgrade, an in-place upgrade has the benefit that the Data Warehouse does not change and the reporting services all remain intact. However, as before, the Management Packs change and get updated and there is always a risk that the ETL jobs have Sync issues that could take a very long time to remediate if possible at all.
- PRO’s
- Data Warehouse connections remain available
- CON’s
- No ability to upgrade OS of SCSM Management Servers and SQL servers
- Downtime for Analysts as the install occurs
- No ability to upgrade SQL version
- No ability to fix Management Pack issues rather than carrying them forward
- Migration and testing must be done using out-of-hours work
- Risk of data warehouse sync failures
Armed with this knowledge, you now have a choice to make…
