Web App Migration in the Medical Industry -
Sailab Case Study
1. Project Context
Our client MedTech Palvelut MP Oy is owned by Sailab – MedTech Finland ry (later Sailab), an association of independent organizations involved in the MedTech industry. For over 20 years they have maintained a medical device nomenclature called Sailab Fennica, which is a tree-like hierarchy of categories to organize a vast assortment of products used in Finland. Suppliers add their own product information to the database, and healthcare providers browse the database to find and compare products, for example when requesting quotes and making procurement decisions.
Before this project began, both the database and the web application which provides access to it were old and difficult to maintain, update with requested changes, or upgrade with new features.
After years of wishing for improvements, Sailab was ready for a modernized system that would be more usable, maintainable, and flexible.
2. The Core Problem
Overall, this project has gone rather smoothly without major problems, thanks largely to Sailab’s good communication with us, allowing time for a current state analysis, and their willingness to participate in the development process.
One of the most challenging aspects was migrating data from the old system to the new system and ensuring its accuracy. We were not able to obtain any database dumps, so the nomenclature could only be transferred via spreadsheet. We wrote a script to interpret the tens of thousands of rows of categories to reconstruct the hierarchy. Occasional differences in the format of category codes added to the challenge.
Product data was migrated the same way, along with some surprises due to limited validation in the old system. Temperatures formatted as dates, currencies as symbols instead of codes, and a few other inconsistencies have been normalized in the new database.
The product data just took some extra time to handle, but the nomenclature data required careful analysis. If the nomenclature could not be programmatically reconstructed from the spreadsheet, the project would have had no practical way forward. Fortunately it was possible!
3. Project Goals
Our client wanted a modernized application providing all of the necessary features from the old system, with some much-needed improvements as well as openness to change.
”Success” in this case has two sides: visible and behind-the-scenes. The visible side of success means having a working web application for Sailab’s administrators and customers to use, and quick support for service requests. Behind the scenes, success is systemic. Reliable services to avoid failures, deployment pipelines for rapid development, and a well-organized and documented codebase to make future changes easy instead of stressful and complicated.
In addition to openness to change, our client also wanted the new system to be more user friendly. The old system had some unintuitive interfaces, and a slow and complicated data transfer process. Data transfer now has simpler requirements and immediate results. We have done our best to make the new website easier to use while keeping some of the visuals familiar to help everyone adjust to the change.
4. Our Responsibility
All of the business decisions were in Sailab’s hands, and WeAre was responsible for all of the technological and architectural decisions to create the application according to their specifications.
The team from Sailab has been wonderful to work with. They provided all of the information they could gather about the previous system to help us understand how it worked and what their requirements were for a new system.
Their team also actively engaged in our scheduled biweekly demo meetings, in which they could see what progress was made during each development sprint. Feedback in this stage helped us be sure we were on track with their expectations, and it can be very motivating for everyone involved to watch a project come to life.
For domain name arrangements, we also communicated some with their IT provider, who always promptly handled requests.
Another crucial part of the process was beta testing. A sample of Sailab’s customers joined in this testing stage to give feedback on what features were useful or still needed improvement. We were able to make adjustments based on their feedback and further ensure that the application will genuinely meet the needs of the people who use it day to day.
5. Technical & Development Approach
Before beginning any development work, we started with a current state analysis to understand the required functionality and potential improvements. By planning ahead this way, we have so far avoided making unwise designs that cause a lot of wasted time and energy down the road.
The database model for the nomenclature was the most important decision, especially knowing as we do that many difficult problems in software development boil down to data structure problems. A poor choice there could lead to endless regrets later. For example, the choice of what to use as a primary key: a surrogate key, or a natural key? Identifying some cases where the natural key might change led to choosing a surrogate ID that will keep the database records nice and stable for product relations. In less technical terms: decisions must be made with future needs in mind.
6. Challenges & Turning Points
The current state analysis was invaluable in getting a clear idea of the scope and potential challenges of the project. We were able to anticipate which parts would be most challenging and allow time for them, such as data migration.
Along the way, it became clear that there was no easy way to migrate user data from the old system to the new without a lot of manual copying of potentially stale user lists. Sailab’s team had a new idea: what if users could migrate themselves by registering with and verifying their company email addresses? Fortunately this was quite feasible and we were able to finish the feature in time for beta testing, so that the first curious customers could try it out.
8. Results & Impact
The project officially launched in January 2026, so it’s still early to estimate impact. But the biggest change may be that our client can now count on us to respond to requests and make needed changes. We’ve already completed a few small post-launch requests, and we’re ready to support them into the future.
Some of the specific improvements for all users: the website now has a more modern user interface, more advanced search options, saved product searches, and the ability to save multiple lists of selected products. And for suppliers: transferring product data is faster and easier, product version history and scheduled changes can be viewed, and various other quality of life improvements have been made.
Our usage statistics show that some users have already started using the new search-saving and list-making features, and some suppliers have successfully used the easier data transfer process to update their products. We look forward to seeing these usage trends continue without major issues.
9. Long-Term Value
The project is built from the ground up with maintainability and flexibility in mind. The source code uses a modern programming language, with tests to ensure critical functionality will not break after making changes. Using CI/CD pipelines, any code change is automatically deployed to the development environment where we can confirm its success before triggering the production deployment. Most changes involve no interruption to services, so there will rarely be any need for downtime. Even database changes are quick and painless with our selected framework (of course, backups are also made in case anything goes terribly wrong!).
To support busy seasons and potential long-term growth, we’re hosting this project with a cloud provider which can scale services as much as needed. Computationally heavy tasks like data processing are handled in worker threads so that the application can still respond quickly to other users’ requests.
The client has gained a much more forward-facing software solution which can grow with them and support their needs into the future.
10. Developer Reflection
As a developer, I’m most proud of seeing this project through from beginning to end (and onward). I’ve more often joined projects that have already begun, and once started a project that unfortunately ended only partly complete when the client reorganized internally. Everything I learned from those experiences helped with planning and delivering this solution, and it has been a very rewarding challenge.
11. Project Snapshot
Project duration: From kick-off to production launch, completing the project took a little over 5 months.
Team size: On WeAre’s side, we needed 4 people to make this project possible, in these roles: sales and project steering, software developer, cloud architect, and service desk support.
Technologies used: TypeScript programming language, PostgreSQL database, Git source control, AWS cloud provider, DocEvent SFTP service
Client industry: MedTech industry
Type of solution: Custom software: full-stack web application