When you have made the decision to investigate migrating your database applications from one database platform to another, the next big question you will need to answer is ‘Which application(s)?’ It seems like an easy enough question but there are many variables involved in whether or not the migration will be smooth. Technically, any application can be migrated…with the right amount of effort. The ‘right amount of effort’ is the thing you need to figure out in order to decide if a move is the right business decision for your company. Let’s talk about some of the important variables that you need to consider in order to gauge whether an application is a good migration candidate or not.
** Packaged, 3rd party applications**
3rd party applications at first thought would be great candidates for migration simply due to their cost. An application like SAP, although technically could probably be migrated to new database platforms, suffer from the issue that the vendor must certify the database platform and many of those large vendors have not adapted to accept PostgreSQL as a supported database. So, 3rd party applications end up falling to the bottom of the list unless you can sway the vendor to take on support of the new database platform.
Old, homegrown legacy applications
This category of applications includes mainframe applications that your company has had for longer than anyone can remember, use older technologies like COBOL for the application language or were originally developed against very old versions of databases and often not upgraded over the years for various reasons. These types of applications should be migrated…eventually. They just aren’t the right application to start a migration endeavor with since the project would take longer and thus cost more. Often, there is a lack of knowledge of the source system since those folks have long since left the company. That means there is a significant ramp up for your staff and migration partner just to get comfortable with the functionality of the old application to make sure that the functionality is maintained in the migrated system. So, our advice here would be to keep these applications on the list and target them for a later time once you successfully migrate other applications and get comfortable with the process and the new database platform.
Line of Business(LOB), non mission critical applications
These types of applications are typically great candidates to start a migration project with. They may be complex but since they are considered non mission critical, you have more leeway in project timelines and more importantly, people are more willing to test out a migration on such a system as opposed to a mission critical application.
Mission critical applications
This group of applications are usually where you will get the biggest bang for you buck when you do a migration since the current costs of the proprietary database platform are astronomical and subject to increases every year. Even if the migration effort and cost are relatively higher, the savings over time far outweigh the investment. Some companies will chose to start with a migration of these applications so they can realize the ROI quickly. Others might tackle these after they have a couple LOB application migrations under their belt. From an effort point of view, these types of applications have many moving parts and typically are tied to other systems so any migration needs to take the impact on those other parts/systems into account. A thorough migration assessment is a must in these cases so everyone involved clearly understands the changes and their impact.
Besides the high level categorizations described above, you can narrow down the candidate pool by looking at the technology used to develop the applications. Some are just easier to migrate than the others. More modern languages like Java, Ruby, Perl, Python, etc are very database agnostic and thus have drivers for just about any type of database. Older languages like C, although still able to be migrated, tend to have more database specific functionality that will need to be worked around. As mentioned earlier, much older technology like COBOL would often be modernized during the migration in order to ensure that current and future staff will be able to maintain the system.
Typical application types include: reporting, oltp, mixed workload(ODS), data warehousing, analytics, web, etc. The type itself isn’t enough to decide if a system is a good candidate or not but it would bring up the right further discussions that would factor in the right variables that will allow you to decide. For example, if you have an analytics database, you’d want to ask yourself the following questions:
- are the analytics performed by a tool, i.e the database is just the datastore?
- does the system use database level analytics?
- If #2 is yes, then what analytic functions are being used?
- Does the list of functions from #3 exist in the new database platform?
- If an analytic tool is used, does it support the new database platform? If not, this is a non-starter.
- What database features are used to support the analytic processing, i.e look for partitioning, parallel query, summary tables, cubes, etc?
As you can see, there are a bunch of variables to consider when choosing an application system to migrate. Each variable leads to more questions meant to give you the right data to be able to make an informed decision that makes sense for your business. In each case, a migration assessment which will give you a detailed view into the effort need to migrate, should be undertaken. Partnering with a open source focused company who has years of experience performing migrations is a good step to ensuring a successful project.
If you are interested in exploring the possibility of starting a migration project, feel free to contact us to start discussing. We can be reached here: http://www.openscg.com/