2

I'm working with a client who is considering upgrading from their current SDL Web 8.5 system.

We are currently considering whether to:

  1. Do a normal staged upgrade (using parallel infrastructure alongside the existing environments and completely separate (but upgraded) databases), or
  2. Do a rolling upgrade, where the new (parallel) Tridion Sites 9.x servers will point to the same (upgraded) databases as the existing SDL Web 8.5 servers.

We're not sure at this point whether to upgrade to Tridion Sites 9.0 or to hold on for the upcoming release of Tridion Sites 9.1.

My question.... Will it be possible to do a rolling upgrade (where both the old system and the new one point to the same (upgraded) databases) if the client wants to go from SDL Web 8.5 to Tridion Sites 9.1? Or is rolling upgrades only available for the last 'point release' - for example, 9.1 can only use rolling upgrades when upgrading from Sites 9.0?

The Tridion Sites 9.0 documentation is vague on this, but obviously the Tridion Sites 9.1 documentation isn't out yet.

Thanks, Jon

3 Answers 3

4

Rolling upgrades are only supported and tested from the previous point release. In this case it means that a rolling upgrade from 9.0 > 9.1 is supported and everything else isn’t.

So, in total, supported:

  • 8.5 -> 9.0
  • 9.0->9.1
  • 9.1->9.5

From 8.5 to 9.1 you'll have to be creative and press on with the upgrade. The most viable route might be a staged upgrade to 9.1.

2
  • Thanks Rai. What would be the advantage of doing the staged upgrade to 9.0 first, and not just going straight to 9.1 with a staged upgrade? Would it be that you could have two version (9.0 and 9.1) available at the same time (and thus reduce the risk of one of them not working as expected)? By the sounds of it, the moral of the story is to keep up with all point upgrades! Jul 16, 2019 at 14:15
  • Fair point @JonathanWilliams. Updated the answer.
    – Raimond
    Jul 16, 2019 at 14:35
2

Remembering the Sites 9 Technical Readiness webinar, it was said that rolling upgrades will only be possible 1 "version" at a time. They didn't specify major or minor, but it makes sense that that "limitation" will apply to both.

In other words, you won't be able to directly upgrade to 9.1 (using the rolling approach), but instead will have to do 2 rolling upgrades: 8.5 to 9 and 9 to 9.1. And I believe this also applies to databases/clients.

You can rewatch the webinar to see whether you also get the same understanding as I did. And if that won't be definite enough, there's always the helpful folk at SDL support as a last resort

1
  • Thanks for the response Atila. You are right, it's only point releases (e.g. 8.5 > 9.0 and 9.0 > 9.1) that will be supported. I've accepted Rai's answer (which says the same thing), just because he's an SDL insider and thus has a definitive answer. Thanks for your (correct) input though 👍 Jul 16, 2019 at 14:39
2

Watch this space Mr Williams. I checked this very question out at he Benelux user group and the answer was that it would ‘PROBABLY’ work for 8.5 to 9.1.

I expressed my concern should it be minor versions for the simple fact that most clients (and of course I’m excluding cloud clients here) are reluctant to upgrade to the first version of a new major (and in my experience not just risk of required hot fixes but risk of time delays for major versions).

If I’ve to undertake 2 rolling upgrades between 8.5 and 9.1 then I’m expected to also perform 2 rounds of testing )one on a working 9.0 version) - if there are issues / the client wants to know if they are 9.0 or 9.1 issues for example (and I’m sure support will start requesting rollbacks etc!). This puts the whole validity of a rolling upgrade in question. Maybe longer-term a minor version would work once rolling upgrades build confidence in actually undertaking at first version upgrade.

~~Anyway - I’m asking for more information. (Formally) and will revert when there’s a definitive answer.~~ >> As per discussions here and {upcoming} update to documentation, the support is for the next major or minor version and no more.

3
  • Thanks Mark. Can you let me know as soon as you find out more please? I agree - only being able to do a rolling upgrade between point versions would have limited use for on-premise customers who rarely go through all point releases. Jul 15, 2019 at 17:41
  • The idea/hope behind rolling upgrades was that if we make it easier to upgrade, it is more likely that customers will be tracking our releases rather than staying on an ancient release (with ditto platform support) for ages, because it is consider too expensive to upgrade. Jul 16, 2019 at 17:23
  • Fair point Rick. It's just that the '1 version' rule wasn't clear on being 1 major or minor point version. On this first upgrade where rolling upgrades have the chance to prove themselves it would just have made a great case to jump 2 versions and say ... see! how easy was that then straight to 1 point rollin gupgrades as standard. Hopefully we can still justifiy a rolling upgrade to 9.0 in the hope it acts as expected and makes the argument for 9.0 > 9.1 a simple one. Jul 18, 2019 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.