Over the past period, we have been through a tremendous workload in order to make TRIMIT fully ready for the cloud and Microsoft AppSource. In this blog post, you can read more about the considerations we had choosing between different ways to do that, what we decided to do and what we have learned from our choice.
A little background
Technology changes are no stranger to us here at TRIMIT. We have been through a number of them over the 30 years we’ve been in business. DOS to Windows, Classic client to RTC and Windows Client to Web client, just to mention a few. So when Microsoft announced the shift from C/SIDE code to AL code inside Dynamics 365 Business Central, we already had an idea about the task in front of us. Still, it turned out to be a huge undertaking.
TRIMIT is a multi-vertical ISV solution, tailored for three main industries: (1) Fashion & Apparel, (2) Furniture and (3) Configuration. The very rich feature set that comes with TRIMIT means that it consists of a fairly large amount of code – equaling a lot of work if we were to convert the whole thing.
So, what options did we consider? Since we knew this technology change would affect our entire solution, it was natural to consider primarily two options: (1) start all over and build a new, cloud-based solution on the new technology, effectively leaving us with two products, and (2) convert TRIMIT as a whole into the new technology to reside in the cloud and on-prem with one and the same code base. We called it ‘Start over’ or ‘Move over’.
The obvious benefit from the ‘Start over’-strategy would be starting with a blank piece of paper and have total freedom to build a new solution from the ground up. We wouldn’t have to worry about how we used to do things, how the current product was structured and the features and functions it had. In other words – total freedom and the option to have a new beginning.
Yet, we ended up deciding for the ‘Move over’ strategy. Why?
We did this for 3 main reasons:
- With a ‘Move over’ strategy, we would have one code base for the product with one feature set. Having two products where one is based on the ‘old’ technology and one is based on the new would not be optimal for our customers and partners – not even ourselves for that matter. It would effectively park our existing customer base on their current product until they would be ready to effectively switch platform to a cloud-version, and we did not want to enforce a choice option to our customers who have been with us for years. Also, with two products, which version would get the most attention and the best new features – the one with the most customers, or the one with the newest technology?
- It is in our DNA to be able to upgrade our customers with every new release, and we didn’t want to compromise on this. We didn’t want to leave any customer behind, stuck on old technology. Instead, we wanted to reward our customer’s loyalty with a direct and secure path from one technology to the next, in this case from on-prem to cloud. After all, our customers didn’t ask for this change so we wanted to make it as smooth as possible to start taking advantage of the new technology and the ability to move their ERP to the cloud.
- The third main reason why we chose the ‘Move over’ strategy was that we spoke to our customers and took their feedback. Our customers rely on the current features of TRIMIT and compromising on the feature set in return for a brand new product was not their preferred option. To go through a technology change in an upgrade and get value out of it, they wanted to be sure they would be able to use the same feature-rich product in the future as they know and love today. It was clear to us that our customers wanted to continue to be on a solution where everybody keep getting the same new updates – they didn’t want to be divided into two groups each with their own solution.
We knew what we had to do. And so we did it – converted the entire TRIMIT solution from the now former C/SIDE code base to the new AL code base. And while we were at it, we took a long, hard look at our product and did some cleaning up and modernization in different areas of the solution.
What have we learned?
After investing more than 20,000 hours (yes, you read that right) in development, redesign and testing, we are incredibly happy with where we have landed this big project. And we’ve had a few learnings along the way as well.
First and foremost, if you are going through this process or is considering it, we would encourage you to keep in mind that the most obvious choice might not be the right one to make. You could argue that the most obvious choice would be starting all over with a new product – but then what about your current customers and their future? Also, it might seem obvious that customers would eventually have to upgrade to the new version, which may be true – but it could take years before all have migrated, and how do you create a credible roadmap and resource allocation to maintain two products in the meantime?
Finally, keep an outside-in perspective to the project. You should look at things from your customer’s perspective rather than the inside-out perspective where you make decisions based on your own best. Have the utmost respect for your customer base and design your technology change process in a way that causes as little disruption and confusion as possible.