@THAero High level that is a good start to a plan. Have you done an upgrade before? How custom are you? Classic screens still or all Kinetic?
We just went through the upgrade from 23.5 to 25.2. Here are a few thoughts based on our experience. Upgrade weekend is risk mitigation for if things go south and not effect production come monday morning.
You can spin up new servers to do all the testing of the new version. Depending on how testing goes, you may not want to do a switcharoo for the upgrade, just a retire.
Then upgrade weekend just restore database to the new enviornment. User will need to install the new client anyway, so having it be the same IP address might not be the biggest concern.
Having the old enviornemnt around might be a good way of failing back to things if the upgrade goes sideways.
Don’t know your envionrment, but if you have a bunch of Kinetic layers you might have to deal with MetaUI folders to get those layers to the new system.
Thanks for the feedback. We are 99.9% Classic and have zero Kinetic/App Studio layers, so hopefully that simplifies things a bit.
We are planning to retire the old servers, but keep the same DNS names where possible so we do not have to repoint things like Power BI connections and other integrations.
We also plan to keep the old environment intact for a while as a fallback in case anything goes sideways during cutover.
The basic framework, yes however what I don’t see is, do you have a testing plan to test any/all changes in the system before upgrading?
The problem with keeping the new system ‘off network’ until go live is that you can’t have anyone test anything really.
To also be planning to keep the same names on different servers as your old ones will also make it very difficult (IMO) to fall back if you do have an issue during the upgrade.
Typically for us we spin up a new App Server (SQL as well if that version is changing) with the server name tied to the version of Kinetic it is hosting and then have each department available to test the system (if a department chooses to not even log in, well that is on them and can result in some real fun on go live day, ask me how I know…). Then once we are at a point where we feel we are good we plan a cutover weekend and re-import the SQL backup fresh and upgrade from there.
I’d also argue that being all classic makes it harder since you will have to reinstall all of those clients instead of just pushing everyone to a URL and mass installing EdgeAgent but there is not much that can be done about that really.
@leonardpothier We have created a bat file to help with the client install. The bat file uninstall old client files and then installs the new one. Make that step a bit easier.
I’ve done the same in the past, we use PDQ so I would have it uninstall/delete the old client, install the new one and then download the full client file so that when the user opened it for the first time everything was done. IMO the browser is still easier though as mass pushing out the edge agent is pretty trivial and does not require a 4.5 gb download onto each station.
Building new servers with the same name as the old servers while still keeping the old servers alive while also being able to test the new servers while not having anything that is connected to the old server pointing to the new server since it now has the same name as the old server is breaking my brain. That sounds like a nightmare.
Build new servers, test everything. You can deploy the client to everybody’s PC whenever you want to but don’t give them a shortcut (makes less work on go live day, and you have time to handle the 75% of people who don’t follow directions and leave their computers on/connected to the network). When it’s time to go live backup from old to new, restore db. Do all of the conversions and bada bing, bada boom. Then change the shortcut target on their current shortcut to point to the new client.
Jose built a tool for migrating SSRS reports. It’s really handy and works great. Just test it out so you understand how it copies folders.