This document is a work in progress and we invite you to send us your feedback.
This document is intended for experienced developers and leads as guidance in migrating Traditional Web Apps to Reactive Web Apps. The migration requires good knowledge of the new front-end features and knowledge of the application architecture. Check our training Becoming a Reactive Web Developer for an introduction.
The migration stages depend on the type of Traditional app you want to migrate, its logic, designs, and architecture, resources, and the time you have available. What follows is an overview that focuses on the steps that might be common in the migration projects. Check the document Traditional to Reactive migration reference for a more detailed technical overview.
Refactor the app to centralize the server calls
You should do some preparatory work before you migrate your app to the new runtime. The first step involves inspecting the logic for server calls and optimizing them by grouping them into a common logic. If your app has complex Server Actions used by Screen, consider extracting some of the logic to Server Actions and reusing them where needed.
Traditional App renders most of the UI on the server side, so the server calls bound to UI were not an issue. This is not true for Reactive apps, where forcing UI to wait for a response from the server makes an app appear slow.
Recreate the Screens using new widgets and OutSystems UI
Reactive apps use the new UI framework, OutSystems UI, and it's not compatible with the OutSystems Web UI or Silk UI. One of the first tasks should be selecting the Layout that fits your app best. Then you need to recreate your Screens in new modules with new widgets and patterns. This implies adapting existing user experience to the new UI and improving it through it.
If your Screens are based on OutSystems 11 Screen Templates, you can recreate those screens using similar Screen Templates in Reactive. You can also use scaffolding to speed up some of the UI creation.
The more complex screens need to be recreated if your old apps are using OutSystems UI Web, Silk UI, or Rich Widgets.
When migrating Themes, you can copy and paste parts of the CSS. However, not all of the CSS classes are the same.
Update the front-end logic
Once the UI is in place, you need to make it fully functional. For the most part, this entails focusing on the logic that now runs in the client. You should check which data you bring to the client side of the app, making sure you always don't expose confidential information.
Fix the performance warnings
Check if your app is running smoothly for the end-users. You should fix the performance warnings in Service Studio, particularly the ones related to using the server-side logic from UI.