Visma Proceedo Migrates to MariaDB unlocking more than 2x better response times and cost savings

A database is one of the most essential elements of an IT infrastructure, enabling the collection, storage, retrieval, management and analysis of data. This data needs to be accessed reliably, at any time and without delay. But when is it time to move from one database to another? What do you have to consider before taking on this project?

Moving away from a legacy database is not an easy thing to do. Migrating large amounts of complex data is a highly specialized task. Thankfully, MariaDB makes it easier by providing database tools, migration services and database experts that help guide companies through their migration.

We recently spoke with Jekaterina Pundani Development Manager at Visma, who shares the lessons she and her team learned when they started the process of migrating to MariaDB Enterprise Server and leaving a legacy proprietary database after over 20 years. She also shares the benefits their business has gained since using MariaDB database products.

What does Visma do?

Visma is a leading provider of mission-critical cloud software helping its 1.4 million customers across Europe and Latin America simplify and automate their business work.

Visma Proceedo is a large purchase-to-pay cloud solution helping businesses automate their entire purchasing process from order to payment. It is a critical application in the Nordic region with almost one million users, processing 12 million invoices yearly. It’s a system that requires zero downtime, no performance issues or data corruption with over 20TB of data.

Why did you decide to migrate off your legacy proprietary database for your Proceedo application and move to MariaDB database products?

We were hitting limitations with the current legacy relational database we were using and we realized it was going to cost us more money if we continued. We started our migration project in May 2018 and completed the migration in September 2020.

The reasons for the database switch included:

• • Our continuous delivery implementation was prevented because we weren’t able to use local databases for our developers
  • Part of Preceedo’s functionality was built on SQL dialect that required additional expertise to maintain
  • Data encryption would require additional license costs
  • In order to handle the increased data, additional hardware would need to be purchased, which would increase the license costs even more
  • The license cost was already too big

Our project goal was to have Proceedo use MariaDB as a backend relational database on production for all customers with at least the same performance as in the previous database and no data loss.

How has MariaDB helped your business?

Once we were in production and Proceedo was optimized for its users, our average response time improved significantly. With our previous proprietary database, it was 1.5 to 2 seconds, whereas with MariaDB we were under 700 milliseconds.

We also saved roughly 10% per year for license and support. By moving to MariaDB, we’ve been able to decrease costs and upgrade hardware as necessary while making improvements such as using replicas for reports generation, local machines, etc. We have also been able to add more storage to handle increases in our data, which doubled over two years.

We’ve gained more than we expected with the awesome MariaDB Remote DBAs. The support and follow-ups we’ve received from MariaDB is so much better compared to our previous relational database! The MariaDB Remote DBA team proactively comes up with improvement proposals and acts quickly when we’re in need of something.

What is the advice you would give another company looking to migrate off a proprietary database?

The top 3 pieces of advice I would give are to make sure you have the correct project goal, a thoughtful project scope, and know what the rollout would look like including downtime requirements as well as build in sufficient time for various testing (regression, performance, load, security and disaster recovery). Our project was much bigger than we realized, which created some delays, but it was well worth it.