When it comes to upgrading your software, tools and programs, the OutSystems platform is no different. New and improved versions are released and, at some point, you want to make sure you are using the latest version so you can fully leverage its power.

On the 31st of August, OutSystems will no longer support any older version of the platform. This means they will no longer work on any support issues including tickets for older versions. 

This article is not going to guide you through a complete OutSystems upgrade – that would require detailed analysis and knowledge about how your company is using the platform and your release cycles. 

Instead, this article’s intention is to share Product League experience and our main concerns when executing an OutSystems upgrade for our customers – in the hope we create some awareness, and that you know at least where to start.

Upgrading is not a minor action

Unfortunately, there is no one-click upgrade button for a simple upgrade, especially when it comes to upgrading a product. Besides new and cool functionality, new product releases may introduce breaking changes, as existing interfaces may need to change, in order for the product to evolve. 

When we are talking about the OutSystems platform, we are talking about a product that allows you to build new products. So you want to make sure that the upgrade does not impact your application portfolio, and consequently, your customers… Even when no breaking changes are documented, you still want to ensure business goes on as usual, and there is no unforeseen side effect to your software.

Ok, so now you must be feeling worried… Great! 

Awareness is the first step into a successful upgrade. The second step is to transform those worries into a plan. Planning allows you to do impact analysis, risk assessment, and determine when and how to upgrade your platform with minimal impact to your business.

When should I upgrade?

Some organizations always want to be on the cutting edge and are always on the latest version – trading stability (of the old version) for innovation (of the new version). These companies are always looking for the new release and join OutSystems early access programs.

Others are more conservative and are one (or more) versions behind the latest. This ensures a more stable version but may be missing the innovation that may differentiate their business from the competitors. Unfortunately, these customers may also miss important security upgrades, exposing their applications to new vulnerabilities.

Product Leagues recommends its customers to be on the latest version, so they can fully leverage the platform’s capabilities. Also, experience tells us that, the further behind you are, the more complex and risky the upgrade will be, so you want to avoid that scenario by keeping your OutSystems platform up to date. Please remember that OutSystems will no longer support older platform versions after the 31st of August.

Product League Upgrade Process

OutSystems understands the risks behind an upgrade, so it guides her customers to make this process as simple as possible – there is extensive online documentation [1] on this topic. 

Product League provides Expert Services that support our customers in multiple areas. We have a specific Platform Upgrade Program, were we combined the OutSystems guidelines with our field experience, and came up with a 4 step approach:

A. Upgrade Assessment

Keep in mind that upgrade complexity increases mostly with two factors: i) the number of the applications you have to upgrade and ii) how old your platform version is. Your very first step is to understand where you are and what the impact is of upgrading your applications. So, gather as much information as possible, to avoid running into surprises at a later stage. Here are some examples of the questions that you need to see answered:

Assess your current landscape:

  • What is your current platform version?
  • What is your Infrastructure? Are you in the cloud or on-premise? 
  • How many applications do you have? Which ones are mission critical?
  • Any third-party integrations?

Define where you wanna go and what is impacted:

  • What is the target platform version?
  • How documented breaking changes may affect your current applications?
  • Does the upgrade imply new infrastructure requirements?

Identify your upgrade window:

  • Do you have any mandatory release cycles?
  • How will the upgrade timeline impact your ongoing projects?
  • Can you have downtime, when and for how long?

B. Upgrade Strategy

After the initial assessment, it is time to define your upgrade strategy. 

The main goal of this step is to make the decisions that allows you to mitigate the upgrade risks and reduce related costs. For example, you need to decide:

  • Environment upgrade sequence: typical upgrade sequence (LifeTime, Development, Test, Pre-Production and Production) vs. a custom sequence;
  • Upgrade applications: how do you upgrade your applications? There are multiple ways to do it, from upgrading all applications in each one of the environments, to doing it just once (Dev) and staging it further;
  • Production Release Strategy: Zero downtime vs. downtime approach;
  • Breaking changes: some breaking changes can be solved in the current version, should you plan for that to happen before the upgrade starts?;
  • Development freeze: which applications stop first and for how long? Will the teams also be frozen or will they contribute, for example, by solving the breaking changes?;
  • Define which teams are working on the upgrade, and their responsibilities: Infrastructure team, development team, operations team, testing team, etc;
  • Deal with the unexpected: how to handle critical production issues during the upgrade?

C. Plan Definition

The upgrade plan is the instantiation of your upgrade assessment and strategy. At the end of this step, you have a clear high-level overview of the entire upgrade. Make sure your plan is as detailed as possible: 

  • Split the upgrade into smaller, actionable upgrade moments. Each moment must have a clear goal and a deliverable. E.g: Solve breaking changes for application A, upgrade Development, Test application B, etc.
  • Create checklists for the critical steps inside a moment. Include all details for the necessary steps to execute the upgrade. It’s the best way to make your plan actionable: everyone knows what to do and when.
  • Upgrade timeline. Define dates for the complete upgrade and for each upgrade moment. Everyone involved must know the target date and how long the entire upgrade will take.
  • Define ownership and accountability. Put the names of the teams and their members in the plan, to ensure responsibilities are clear.
  • Identify team dependencies.  Examples: In a multi-project software factory, it’s fundamental that all the PO’s agree on a timeline to minimize the impact of the release cycles; The testing phase cannot start before the breaking changes are executed by the delivery team, etc.
  • Plan regular status meetings. To promote alignment and discuss eventual adjustments.

D. Plan Execution

The final step is, of course, the execution. The more complete your plan is, the smoother the execution will be. A plan with a lot of variables tends to be a lot more unpredictable, opening the door for failure. 

If something goes wrong, do not panic – regroup and revamp your plan. Of course, now you are running against the clock… so it’s always better to invest more time in the preparation phase.

 

Wrap-up

Hopefully this article will help you not to oversimplify the platform upgrade but provide you with insights and attention points for a successful upgrade! There’s much more detail to add in each one of the steps that we mentioned. For those we advise you to take your time and analyse the best upgrade option considering your landscape.

For you to be successful, planning is fundamental. Even if you have a simple landscape, you should not skip writing an upgrade plan. As long as you invest the proper time and resources, the platform upgrade should be just another side project. 

Experience tells that having someone in your team that has executed upgrades before really speeds up the process and mitigates risk. So, if you need additional guidance or support, feel free to contact us at Product League. Our expert team is ready to share their knowledge.