L'ERP low-code maîtrise la complexité

How we design a legacy business application migration?

Migration of a legacy ERP system always relies on more or less the same steps.

1. We go through all the user journeys with the end-users on the existing software.
2. Take notes of every screen of the app: what are the fields, what are the actions, what is the flow.
3. We start to design the new data model in Supabase (What defines a Model? What fields for a Customer? What workflow for royalties? What format for an Invoice, etc...).
4. The next step is to design user flows and high-level mockups of the main interaction screens. Olga, our Product Owner, prefers using Miro boards, which are easier to grasp for non-technical clients like Joly Design. They can see the flow, screens, and ask questions and comment directly on the Miro board.

You might ask why we didn't start designing directly in Retool, with short iterations as we did on other legacy application migration projects?

Well, it seemed to us that we needed more time to fully design the whole process and workflow before rushing into application screens. The main reasons were that non-technical clients need more time to embrace the complexity of their own processes, which they are used to executing but have more difficulties synthesizing and building their own mental model. We usually add this first design step with very complex projects or very non-technical clients.

How went this legacy software migration to low-code?

Very well! We quickly designed screens to manage models. Handling high-resolution images was a challenge, as Retool isn't really made for artists, so a few tweaks were necessary. Integrating the Fidealis API was quite a task too. It’s crucial for patent deposition, where each model designed by Joly Design must be deposited and timestamped by this third-party service provider. We also ran into some back and forth trying to build a simple yet secure way to present designed models to clients. Previously, PDF pages were manually created with designed models and sent by mail to the client. This ended by creating customer portal pages where they can now select models like on an e-commerce site, add comments, and remove models they don’t like. An amazing way to communicate between designers and clients.

Importing royalty files was quite a complicated task too, as we had to deal with many different formats. We ended up creating middleware that transforms those formats into a single pivot format, which was then imported into Supabase.

Oh, by the way, we forgot to talk about why we preferred Supabase to Xano for this project. The reason is that when we have a lot of financial reporting, direct SQL queries are way more efficient than writing tons of different complex endpoints with Xano. We can write complex SQL queries with a lot of variables and generate almost any kind of report with a few queries. Our rule is then simple: if we have a lot of JOINs and complex multi-table queries, it’s probably better to use Supabase. While if we have complex business logic with algorithmic crunching of data, Xano is way better.

Finally, the migration was a challenge too, as we needed to extract data from a 20-year-old, on-premises Windows 2000 server, with only TeamViewer access. No one had ever used Windows 2000 in our team. Oops, we had to learn with tears how awful Microsoft products can be :)

In the end, once we trained everyone at Joly Design, they were happy users of new powerful software. But more importantly, we saved their 70,000 models and offered them a way to continue designing furniture for your butts for the next 50 years.

‍