I’ve learned many lessons over the years on how to execute successful database modernizations.
These projects are rarely ever straightforward. The world is full of talented database engineers and developers, yet many modernizations fail. Why? Because experience matters tremendously in this area.
Database teams must have a holistic understanding of what it means to modernize a database. This includes knowing how to effectively serve the database, the development team, and the overall DevOps function. Without this comprehensive approach, database modernizations fail or take much longer (years instead of months).
Here are six lessons I’ve learned about database modernization:
Lesson 1: Determine Appropriate Test Cases in Advance
I initially expected the companies I work with to take the lead on the testing side of things. However, I’ve since learned that we can’t rely on customers for appropriate test cases. Many aren’t ready or haven’t thought enough about their database modernization testing strategy.
That’s why I recommend spending more time discussing testing during the early stages:
How will you test the target application?
What are the most critical test cases?
Who will do the testing?
Do those people have the right skills and capabilities?
Is automated testing included in the plan?
Answering these questions in advance is crucial for ensuring modernization success and keeping things on schedule.
Lesson 2: Establish the Development Environment
The development environment is another piece that often gets overlooked in database modernizations. I’ve been in situations where I’ve left the development environment out of the project’s scope, thinking the client had it under control. After diving in, I was then surprised to find nothing was ready on the development environment front. As a result, I’ve had to create change orders to do the work ourselves. I now make sure to validate the status of the development environment early on before getting started.
There are two important factors here – the environment itself being suitable for development (IaC, CI/CD, etc.), as well as data that are used during tests. This can be a test environment, rather than DEV, but it’s still very important for development teams.
Lesson 3: Don’t Assume the Customer Understands the App
I’ve also learned that some companies don’t know everything about how their applications work. IT teams change, and applications grow increasingly complex over time. You can’t assume your clients know the inner workings of their target applications. This, of course, makes it difficult to estimate timelines and costs.
So, it’s important to validate that companies have a deep understanding of their applications and databases. If they don’t, your timeline estimates should be at least 2-3x 5-10x longer. My general philosophy is to double-check everything based on my own application assessments.
Lesson 4: Define the Cutover Time in Advance
I’ve assumed in the past that cutovers would be quick and seamless, similar to how they are with standard migrations. I generally schedule cutovers during a single weekend for those types of projects. The problem is that database modernizations never follow this pattern.
The main reason is that companies have data for all of their own customers. Therefore, they usually want to execute cutovers in phases, like 10 weekends in a row versus getting it all done in one weekend. Practically speaking, this requires more PM hours and a longer project for your team to execute. If the cutover strategy is not discussed in advance, you may end up writing many change orders and spending far too long on one engagement.
It’s important to stress that a “big bang” migration – in which applications and data are all migrated in one operation – significantly increases risk. Phased cutovers are the best practice.
Lesson 5: Adopt a Flexible Staffing Model
The resources you need for a database modernization project change as you progress. You’ll often work with the customers for several weeks, or even months, to first scope and prep the project.
This means you don’t have to onboard database developers right away, which is what we used to do. You can wait until you and the client absolutely need those resources, allowing you to keep those experts busy on other projects.
The same thing happens at the end of projects. Database engineers may continue working, but the application development team is not needed anymore.
Lesson 6: Performance Testing is Essential
Years ago, when I was new to database modernizations, I assumed that if we migrated from something like Oracle to PostgreSQL, I would only need to modernize the underlying codebase. The truth, however, is that adopting a new database solution doesn’t automatically lead to better performance.
Some features that work quickly in Oracle won’t in PostgreSQL. That’s why performance testing is paramount, especially given that database migrations and modernizations are commonly the first time in years that organizations test systems in their entirety. Even more, these tests may lead to the need to rearchitect certain business processes because they will not run fast enough on the target database.
In conclusion, database modernization is a complex and challenging process that requires careful planning, execution, and testing. It is important to have a holistic understanding of what it means to modernize a database and to consider all aspects of the project, including testing, development environment, application understanding, cutover time, staffing, and performance testing. Organizations that do not take these factors into account risk project failure or delay, which can be costly and damaging to their business. By following best practices and working with experienced professionals, organizations can successfully modernize their databases and reap the benefits of improved performance, scalability, and cost savings.
About the Author
Pavel Vasilyev is the CTO at ClearScale. ClearScale is a cloud-native systems integration, strategic consulting and application development company founded in 2011. The company designs, builds, integrates, and manages complex infrastructures and applications on AWS exclusively. ClearScale has successfully delivered more than 1,000 cloud projects for clients ranging from startups to large enterprises and public sector organizations.
Featured image: ©writerfantast
