Migrating to OutSystems ODC

OutSystems customers are at a pivotal moment as they consider moving from O11 to ODC. This transition mirrors the paradigm shift toward microservices architecture. While some have already navigated this journey using different technologies, it is time for the OutSystems community to leap into this new modern architectural landscape.

Understanding the transition

Moving from a monolithic architecture to microservices entails splitting our applications into services and orchestrating them together. Although this poses challenges, such as architectural restructuring, the long-term benefits are substantial. We gain a more flexible deployment model, improve scalability, and adopt modern frameworks such as AWS Lambda and containers.

The Four Milestones approach

OutSystems recommends a four-step approach to guide us through this migration journey: portfolio assessment, code preparation, code migration, and data migration. Today, I will focus on the first two milestones, leaving the remaining steps for subsequent discussions.

1. Assess Your Portfolio: Before diving into the migration process, it is crucial to assess your application portfolio. OutSystems is developing automated tools to aid in this assessment. Alternatively, leveraging discovery methods or consulting with firms such as PhoenixDX can provide insights into your architecture's readiness for an ODC migration.
   
   
2.  Prepare your code: The second milestone involves making structural changes to your code and applications. This phase has seven key steps, and I will provide a brief overview.

• • Organise Your Architecture: Begin by structuring it into layers. This lets you identify modules that will transition to ODC as distinct services. For instance, segregating UIs, services, and libraries lays the groundwork for future migration.

• • Embrace Domain-Driven Architecture (DDA): Isolate domains within your architecture to establish isolated contexts. This prepares your applications for eventual decoupling, ensuring they can function independently. While full decoupling isn't immediate, laying the groundwork now facilitates smoother transitions later.
    
    
  • Utilise Architectural Assessment Tools: Automated tools will soon be released to evaluate the readiness of your application architecture for ODC migration. Address any architectural deficiencies before proceeding to subsequent steps.

• • Transition to Service Actions: Replace server actions with service actions to facilitate loose coupling between applications. This step promotes independent deployment of microservices without impacting others, enhancing scalability and maintainability.

• • Adapt to ODC Features: Adjust features like extensions and database entity access to align with ODC's requirements. Containerisation and domain isolation introduce nuances that will likely require rearchitecting parts of your application to ensure compatibility.
    
    
  • Address Unsupported Features: Evaluate and modify any features unsupported in ODC, such as BPT and SOAP. Rethink their usage within your applications or find alternative solutions to mitigate migration obstacles.

Conclusion

As we prepare to migrate to ODC, we must approach each milestone methodically. By assessing our portfolios, implementing structural changes, and adapting to ODC's features, we set the stage for a seamless transition. I look forward to further discussions exploring the upcoming milestones and the exciting possibilities ahead in our ODC journey.

This content was originally part of an Australia East Coast OutSystems User Group presentation entitled Swift Shift: Effective Strategies for O11 to ODC Transition.

Author: Leonardo Fernandes, Expert Services Lead and OutSystems MVP @PhoenixDX