The Pain, the Panic, and the Progress: A Field Guide to Legacy-to-Web Migration

Valentina Caruso at UXDX Community: From Legacy Chaos to Web Clarity. Video: https://youtu.be/B-73ghes3j8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Migrating the technology but not the experience

[00:00:07] Hello, hello everyone, and good evening. It's a pleasure for me to share the pain, the panic and the progress that we have seen while addressing our migration project from the legacy system to web. Just a clarification: we initially started with a migration from legacy to web, but along the way we decided to take the next step and move to the cloud. We are currently halfway through the project, meaning that part of the system has already been migrated, but there is still another part that is in transition.

[00:00:45] I would like to start with a question for everyone, and maybe people can write something in the chat. I'm wondering if you have ever worked on a web or cloud migration, either as developers or product people or other internal stakeholders, and thought: okay, now we will rebuild the front end, we will fix a couple of APIs, we will add some lipstick, and then we are done. In six months, in nine months, we will have something ready. And then you might have ended up with more complex code to maintain, maybe even a more rigid design, and eventually even customers thinking that the solution was much better before.

[00:01:32] The reason this happens is that very often we migrate the technology. Very often we focus on the technology, but we really underestimate, and we don't really retain, the experience, and what that means for the entire company.

Vitec Fixit and the salon system we are migrating

[00:01:53] Before jumping to the challenges that I'm going to present and how we have approached them, I would like to say a couple of words about who Vitec Fixit is, the company addressing the rebuild. Fixit is a company providing digital solutions for Norwegian hair and wellness salons. Our main customers are the beauty salons. We provide digital solutions for booking appointments, but we also provide digital solutions for supporting the relationship with product suppliers.

[00:02:29] We have three main core products. We have Fixit Online, which can basically be considered an administration tool for salon managers and employees. Then we have Fixit Salon Data, which consists of the hardware and software that customers use for running their daily operations at the salon. And as I mentioned before, we have booking channels for end users booking appointments.

[00:02:59] When I'm talking about the rebuild, we are focusing on Fixit Salon Data. What we are migrating is the operational tool that every employee at the salon uses for running their business. This is the place where they manage the shifts for the employees, where they manage the bookings, where they manage everything that actually happens at the salon daily.

[00:03:25] But as you can already see, we have a very outdated UI. I have to say that the system is functional. The system is working as it should, but it's not modern at all. We are dependent on specific hardware or equipment, which makes flexibility a problem, because our customers have been saying that they really need a system providing flexibility. They want a system that can be used anytime and everywhere, and today we're not supporting that need.

[00:04:01] On top of that, this is a system that relies on a very old technical foundation. The system is built on Clarion, and when I say Clarion, I can really feel the pain of our developers. Every time they have to update, or release a new version, or if you want to scale or integrate with modern tools, it's almost impossible.

Why we are migrating

[00:04:28] Concretely, the reasons why we are migrating are, first of all, scalability, because we want to expand internationally. We want a system that is able to grow with us, and we also want a system that is able to support more customers. Today we have very high operational costs to maintain the existing functionality, so we want a system that can be more efficient. And as I said before, we want a system that is hardware independent, which doesn't mean that we want to get rid of the hardware, but we want more flexibility, or even more freedom, to decide which hardware is our best choice, the best fit for us.

[00:05:23] And of course we want to improve our customer experience. We want to really ensure high performance, even during load spikes. We want a system that supports flexibility, and a system that is also modular, because one of the pieces of feedback that we have collected from customers is that customers want to use only the functionality that they need. Since customers have different needs, providing a solution with hundreds of functions is not very convenient. So we want a modular system, really supporting a better customer experience.

Where to start: a failed first attempt

[00:06:03] Challenges and approach. I think that migrating a legacy system is one of the most complex projects that developers, product people and other technical people can experience in their careers, and we haven't been an exception, because we have faced several challenges. The first one may be obvious, but we were really wondering how we should start, where we should start. This is a problem that most companies face, because often even the most experienced companies might not have proper project management skills.

[00:06:49] We made several attempts. The first one was creating a project group back in 2022. What we did at that time was create different groups of people to focus on specific areas. For example, there was a group focused on business, another one focused on brand, innovation and technology, and we were spending 50% of our time on the migration project.

[00:07:16] But we completely failed, for several reasons. First of all, we had a lot of focus on innovation. We were trying to address the new functionality, but we ended up with deadlines slipping by several months, and no existing functionality was migrated. We definitely had a lack of project management skills, meaning that we were not aligned on the goals. The scope was very, very undefined, and we were wasting development time. And we were definitely also tempted by other projects. Everything looked like a priority. So delivery stalled completely, and people started losing credibility in what we were doing.

[00:08:06] Then what did we do? We just started. Because what is important to mention is that the first step, even when it's uncertain, is what opens the way. So we started small, meaning that we split the project into several modules, each module representing the functionality to be migrated, like sub-projects. Then we learned fast based on each module, and then we scaled. We are still scaling our way of working. So our principle has been guided by evolution rather than revolution, step by step.

Choosing a technology without knowing the full scope

[00:08:46] Even though the perspective that I'm bringing here today is from the product management side, we have really been sharing the pain with our developers. For our developers, it has been particularly hard to decide what kind of technology to choose. The reason is simple to understand: how can you actually pick a framework if you don't completely know the scope of the migration? Making a mistake at that point could really cost rework and money in the long term.

[00:09:32] But we tried to follow some guiding principles, like scalability. We had a checklist: okay, is the technology that we're going to choose able to grow with us, supporting our need to expand? Is this something where we need to invest in more resources, or do we already have the skills? Is this a technology that permits working well with other systems, with other products? And is this also something that can support a better user experience, with a more responsive design?

[00:10:13] Based on those questions, our development department decided to focus on Flutter, for several reasons. Flutter can offer cross-platform support, meaning that the development cost can be reduced, but also the maintenance. Flutter is very important from a UX perspective, because the UI looks the same on iOS, on Android and on web, and even behaves the same way. And for the developers it was also very convenient, because Flutter uses Dart, and Dart has similarities to JavaScript. So for the existing web developers it was a smooth transition into Flutter. We didn't need to hire new people, because we were already pretty much prepared to use it.

No documentation of the existing product

[00:11:07] For me as a product manager, but not only for me, one of the main challenges that I experienced, and we are still trying to address this, is the lack of documentation. What does that mean? The problem in this case was: how can I, together with the developers, really estimate a timeline without having any documentation of the existing product? If you don't have anything mapping the existing functionality, and you don't even know yet what kind of improvements you're going to make, how can you really estimate how much time this is going to take?

[00:11:51] Our approach was that developers had to map the existing functionality from scratch. It has been painful, but it has also been very helpful. For each module, developers and the product manager document everything, including the product specifications that are based on the design that we propose. We are trying to centralize the documentation using SharePoint and project pages. What we have seen so far is that having everything documented has enabled roadmap estimation, so we can be even more precise. But on the other hand, this means that our timeline is dynamic, because even though we have some flexibility, each timeline is estimated per module, meaning that in the long term we might have deadlines that are less predictable. So we are still working on it, but it's a compromise that we are applying at the organization level.

Cross-department misalignment and the expert group

[00:12:55] We also had cross-department misalignment. This is also one of the reasons why several migration projects fail. At that point, we had one department, the development department, which also included the product team. The product team really wanted to migrate to improve the customer experience. In the product team, most of the people have a background in UX, so imagine how important it was for us to improve the customer experience. On the other hand, the development department said they wanted to maintain the existing infrastructure and not really touch the architecture. And then sales wanted to have new functionality from the beginning, to sell easily.

[00:13:46] So the problem was that we had conflicting priorities. Every department was focused on something different. Then the meetings became tense, meaning that we were debating everything: what to do first, what kind of scope we should have. There was no real alignment, and this was creating delay.

[00:14:04] What we did then was split the dev department into a development department and a product department, with the existing people. Then we created a group of expert people with knowledge of the legacy system, and each of the experts represented one of the departments in our company. They were helping clarify what needed to be addressed, what could be prioritized and what could wait. Then we split the migration into different modules, each module representing functionality to be moved, and we shared the roadmap.

[00:14:39] What we have seen so far is that we are becoming more aligned on the goals, and we also have clearer decision making. We have addressed the most complex modules so far, and we have seen that those modules have technically been delivered quicker and with higher quality. On the human side, we have also seen that we're rebuilding trust internally. We really see people being more confident in what we're doing, and we are building a foundation for new, scalable ways of working across future projects.

[00:15:22] The process that we have implemented so far is inspired by agile. At the start of each module, we gather the expert group, where UX and the product manager also attend the meeting. Then we discuss a list of pain points and customer wishes. Based on this workshop, the product manager and the UX designer get together to prioritize the pain points and wishes to address in the first version. The designer creates the design ahead of development, and the design is discussed quickly and validated together with the tech lead, so we check the technical feasibility before starting the implementation. And then we keep this review loop, where everything is double-checked with the expert group, together with the developers and the tech lead, before jumping into development.

[00:16:21] So the ownership in this case is also shared. What we have really seen having an impact is that UX and technical feasibility are aligned before development starts, and this saves wasted effort, but also time.

Balancing resources with one UX designer

[00:16:42] Another challenge that we had in the beginning was balancing the resources. I think this may be a problem mostly for small companies, where there aren't many resources, where you can't have just one person dealing with one specific task. Usually in smaller companies you have one person dealing with multiple tasks, and this is what was our case.

[00:17:12] This was the way we were organized. We have basically three development teams. Two of them are working on the migration project, but at the same time they are also dealing with B2B product maintenance. And then we have the third team, which is not involved in the migration project but is dealing with the B2C product. The problem here, the red flag, was the UX designer. We only had one UX designer, focused on the B2C product, on the B2B maintenance, and on the migration. So it was split across three different teams, but it was just one person. That situation was overwhelming.

[00:18:01] What we did to help was to really try to have a selective migration. We identified the legacy functionality that we could leave as it is, to reduce unnecessary workload, and then we prioritized UX where it matters the most. Meaning that we spent more UX effort on the functionality that requires frequent interaction with the customers. This means that the UX designer is mostly working with one of the development teams, which has major UX input, while the second development team has been working with minimal UX input.

[00:18:45] Later, we were lucky enough to be scaling the resources, so we decided to hire a second UX designer to help maintain the existing solution but also deal with the B2C product. Of course, for the designers that's been a relief, but we have also seen improvements in productivity and efficiency, because people need to be well to work well.

When to involve customers: a pilot group

[00:19:11] Last but not least, we also had a UX challenge, a particular one. I cannot really go into the details in this case, but our main dilemma was when to involve customers. Given the complexity of the migration project, you have to consider that if you involve customers too early, you risk overpromising, meaning that customers may expect improvements that won't be addressed in the first version. But on the other hand, if you involve customers too late, then you risk discovering UX regressions, important UX issues that need to be addressed. And if you find them when it's already too late, this is going to cost a lot, in addition to the wasted time for the developers.

[00:20:04] The solution that we decided to apply was to create a group of pilot customers. We selected representative customers based on specific criteria, and then we had an agreement with them: they agreed to participate in monthly testing and feedback sessions. But the real usability testing happens after completing each core functionality. So we allow customers to test in a more realistic environment: they're testing in the testing environment.

[00:20:41] This has been working very well. The result has been that we avoid delays from premature customer requests. Customers are not really expecting new functionality there. They're just expecting what we agreed. We are collecting more realistic feedback because, as I said, we're testing in the testing environment. Having just a prototype addressing all the interactions that they have wouldn't have been really convenient. And customers today feel very involved and very valued, which creates stronger loyalty, and we have also experienced that early adopters are becoming our promoters.

Lessons learned so far

[00:21:24] The lessons that we have learned so far are mostly four. It's more than four, but to summarize: cross-department collaboration should really be addressed. It's not just technology. It's also the context and the way you work with people. When the departments and people collaborating together are not aligned, you are creating conflicts, and conflicts create delay. So our solution was to split responsibility and align everyone through a shared roadmap, which means faster delivery, but also higher-quality modules.

[00:22:07] This has also created a better atmosphere, and people trust each other. When we were building the expert group, we were ensuring the feasibility check happened earlier, and developers also feel safe, because they know exactly what to expect.

[00:22:25] Documentation: documentation is not just a nice-to-have, it's a must. As a product manager, it's very hard to estimate a timeline if you don't really have anything to start with. So our recommendation is to start centralizing specifications. When I say specifications, I mean both product specifications and technical specifications. Try to centralize them so that you can have a more realistic plan.

[00:22:56] And definitely customer involvement. Spend some time, really spend some time, to understand when is the best moment in your project to involve customers, because you can really risk big UX regressions if you don't address customers at the proper time. So our recommendation is to create a group of pilot customers, someone you can easily talk to and share monthly feedback with, and then try to create an environment where you can get realistic feedback. That creates loyalty and a strong relationship with your customers.

[00:23:38] Of course, as I said, this is still an ongoing project, which means that we still need to prioritize what to migrate. We still need to address the existing solution that we have, but we also need to address how we should speed up the process, to be ready for the market as soon as we can. So this is what we have experienced so far, to have a better way to synchronize, or at least to have everyone on board, when addressing the migration. Thanks a lot, that's all from me.

Q&A

[00:24:19] Host: Excellent, thank you very much, Valentina. I loved how in-depth and real those problems are, because I've witnessed a few of those myself in my time.

[00:24:34] Valentina: From which perspective?

[00:24:36] Host: I guess it's the challenge of the project dragging on. And actually that leads me to my first question. It was great the way you decided to break it up into modules. But when you were describing it, you said you would get your expert group and they would define the scope. I've seen cases where the whole wish list still gets pushed into that one module. So yes, it's smaller than the entire system, but you still have scope creep at the module level. How did you deal with that?

[00:25:06] Valentina: This is something that we are still working on. But basically, one of the pieces of feedback that we were collecting from the developers was: okay, is it the expert group who has the ownership to decide? And then we clarified that we have those workshops with the expert group to collect everything we need to understand, but then it's the product manager and the UX designer defining the scope. We need to prioritize. Unfortunately, we can't do that considering the entire project, but this is a flexibility and a compromise that we have to keep. We clarify the scope within each module, but we are taking a stronger position as product managers, and I have to say also as UX designers, to prioritize what really needs to be prioritized, considering everything. Considering all the tickets, all the top tickets that you have: pain points, wishes, stakeholders' opinions as well.

[00:26:10] That's how we are trying to really manage this. But it's very important to have that group of people. It's more like a political strategy, if you know what I mean. You really need to align everyone. When you're addressing a migration project, it's not only for developers or for product people, it's for the entire company. Everyone should believe in it. So if you have everyone on board, you have to work with compromise. That's what we have experienced, but yes, I can definitely see your point.

[00:26:46] Host: No, I 100% agree. Unfortunately it is political, and some people like to shy away from that, but you can't make everybody happy. There have to be compromises somewhere.

[00:26:58] Valentina: Yes, exactly. And usually product people are the ones who really need to find the compromise, because usually we work as a bridge between developers and the rest of the company.

[00:27:14] Host: Excellent, and that brings us to time. It's a lovely note to end on, product being the bridge between the business and IT. Thank you very much, Valentina, for sharing your case today. I really enjoyed it, and I hope everybody out there did as well.