Here we are with another series. In this one we will be going through an interesting one which I think has also been covered many times in terms of step by step guides and some breakdowns of this particular subject being whether to upgrade your SCCM environment directly or to perform a side by side migration.
There will be many parts to this which we will look to carry end to end on not necessarily a how to do step by step guide perspective but more on a high level design approach.
It's always been said (well mostly) that the best option is to always perform a side by side migration which would be to build a new infrastructure and recover your SCCM environment to the new one as it provides the most security by maintaining your original environment whilst you can not only prepare and environment on the side but perhaps have a window of opportunity to add in some necessary tweaks and updates to it as well.
In perfect world scenarios I think this would reign true many times. However realistically this isn't always the case. First we should outline what are the scenarios that would prompt someone with making this decision. Lets have a look at a bullet point breakdown of some of them below;
There are many more scenarios of course which carry weight to the decision making but these are perhaps the most common and most relatable to a lot of architects and system centre specialists.
With these scenarios being monsters its understandable why you would opt for a side by side option. The worst thing you would want to do is to be responsible for the only environment or the most business critical service to be interrupted.
Disaster recovery can also play a factor in this. Due to the fact there may not even be one or one which is not tested? You wouldn't want to wait for an actual disaster scenario to occur to know if it actually works or not :) This provides you with the opportunity to take action once you are in a position to start working on the new environment.
It can be a case of perhaps not having the luxury of resources to entertain a new environment to migrate to, but also can be down to how embedded those business critical resources are. We know that all environments are not the same though there maybe some similarities.
I have seen it where things such as security reasons can play a factor. Where depending on how the environment was built there could be some due diligence that may have not been carried out were certain security levels are unknown on deeper levels such as service accounts, ports, storage and many others. You can even come across environments which also may or may not have an HLD or LLD with them, hence where if you did go to a side by side migration then potentially you are looking at an entire redesign of the SCCM environment. Now that's not a bad thing at all, but a lot of environments can have caveats of business and time critical matters which make the likeliness of those options not come to fruition.
Now using the exact same scenarios in which we listed above, we will provide a small line or so to state as to what the reasons could be to support this option going forward;
It can indeed save time to perform all of this on the same environment. But one thing that does have to be factored in is of course the high level of risk in which it carries. See performing in-place upgrades isn't necessarily straight forward. There are ALOT of processes which have to go into each part of the staging and if one of those goes wrong you could potentially damage your environment as well as the particular server in which you are looking to upgrade.
These are things to definitely take into account when approaching this.
The aim is to cover each scenario in full detail and not to provide a bias to one side over the other. Now if we have learned anything over various best practices and preferential ideas is that the perfect world scenarios won't always cover a real world scenario so therefore we have to accommodate both outlooks. It's not about making or forcing someone to adhere to a specific narrative of this is the only way, but to understand what the risks and dependencies which are covered in each one.
We want to allow someone who is putting forth the design idea with enough evidence to backup the reasonings behind the decision and if that particular scenario is fitting. Comes down to the old saying of make the solution fit the business and not the business fit the solution.
The second part we will be looking at the first bullet-point which we had mentioned in both scenarios being the Operating System. This is of course the foundation of anything moving forward before we begin to piece together the other parts as depending on which versions we might be on the OS is going to determine what we can and can't do in the long run. So the second part will analyse these steps and again accommodating both options.