Hurdles in migrating to ODC

With OutSystems Developer Cloud (ODC), OutSystems offers the newest innovative, up-to-date platform for developing enterprise-grade software. It is the latest and greatest the company has to offer, and it is only getting better with features like generative AI integration and event driven architecture.

But every upside has its downsides. Before every migration it is important to be aware of the risks and technical difficulties you might encounter during your journey, so you can think of mitigation strategies. Today we want to focus on those issues.

Migration to the cloud. Photo by Chris Briggs on Unsplash

Application & Architecture

First and foremost, if you have a filled landscape, with many applications running, migration becomes more challenging, especially if applications are built as Traditional applications. ODC apps are built in Reactive, and since there is no easy way to migrate from Traditional to Reactive this can require a lot of time and effort. For more information check out this article on transitioning from Traditional to Reactive.

If your apps are Reactive, they should follow a domain-driven design, since this will better support the microservice architecture that is native to ODC. If you have not adopted this architecture currently, it may be beneficial to start preparing your applications to ease the transition later on.

When your portfolio is up to date with a domain driven design, it is time to migrate. Smaller applications can be brought over by manual labor, but bigger apps require more work. OutSystems already announced a migration kit supporting migration to ODC, but as of yet, it is not generally available. A version that is suited for smaller applications is expected to go live later this year.

Features & Code patterns

Some features of, and code patterns in, OutSystems 11 will no longer be available, or are not yet available in ODC. If you use these features in your applications, migration will require (extensive) workarounds. Here are some of the differences that stand out:

• Consuming (and exposing) SOAP APIs. This is not supported in the platform, but you can create your own extensions that consume the API and can be referenced in your apps. As SOAP is unlikely to be supported in ODC, you should also explore the possibility of switching to REST APIs.
• Business Process Technology. BPT is not available currently. However, with the new event driven architecture feature light BPT flows are already possible in ODC. A new feature that has additional functionalities is expected at the end of this year. Because it is not a direct copy of BPT, you might be required to (partly) redesign your BPT flows.
• Multitenancy. At the moment, multitenancy is not supported by the platform. If your applications require distinguishing between tenants, you need to create your own system for it. Currently, there is no announcement on availability, so it is unlikely to be implemented in 2024.
• Referencing System Entities. In OS 11 System Entities were freely accessible from our applications, this will no longer be true in ODC. Only the User table will be accessible (as a cache). We will likely see APIs that expose some information appearing in the future. However, the exact content of these APIs is unknown. OutSystems plans to release these later this year. Either way, it will mean that using system tables directly in your aggregates and advanced queries will be impossible.
• DBMS. In ODC developers and platform engineers no longer have a free choice of DBMS. Only AWS Aurora is supported, which uses PostgreSQL. If you currently use another DBMS, your advanced queries may have to be updated. This is unlikely to change, so it will remain a hurdle that needs to be overcome.
• Public elements. With the changed architecture of ODC also come changes to which elements can be public and which cannot. For example, static entities in libraries, roles, structures, and extensions are handled differently by ODC, compared to OS 11. Additionally, server actions can only be public in libraries, service actions are required for exposing actions outside of applications. These are changes by design, so they will remain a concern.

In working with ODC, we experienced some additional challenges, for example error logging not being as fleshed out as it is in OS 11 and not being able to use application-based IP filtering. This is to be expected of a (relatively) new platform. Additional features and improvements will continue to be rolled out the coming months and years, so we expect to see ODC catching up with OS11 pretty fast. The timeline of these improvements may differ on a per issue basis though.

Conclusion

Summarizing, there are some features not yet available for ODC that are there for OS11. A lot of these features are expected to become available this year. However, a lot depends on which features you need, and the impact they have on your applications. Therefore, the question when you should migrate to ODC is specific to each company and should be answered by assessing the impact of migration on your own application landscape.

If you need help in auditing your current situation and determining the best approach, we at LINKIT are the ones ready to accompany you on this adventurous yet rewarding journey. Our team of OutSystems expert consultants and developers have the skills necessary to guide you and explore the best choice for your specific case. Let’s explore this ODC cloud-native word together and unlock the full potential of your digital transformation journey!