Migration is the process of moving from one billing system to another. It involves a kind of translation of data. Although ModernBill v4 and v5 are similar, they were actually designed and built independently, with different code bases, architectures, and database structures. That makes moving from one system to the other not an upgrade or an import, but an actual migration. Upgrading involves making change to an existing system that does not affect the actual data, but the way that data is used. Importing involves taking one set of data from one place to another. Migration involves moving an entire system. When you move from v4 to v5, we attempt to bring not just data, but the essence of your entire system across. To make this process easier, we will discuss in detail what is involved in a migration generally, what you can expect from our migration script, and how best to make it work for you.
Migrations, Broadly Speaking
All migrations follow a basic process. They start with two systems, referred to as the production system (the one you're using now) and the development system (the one you'd like to move to). Ultimately, the goal is to transform your development system into a production system so that the downtime involved in actually moving from one to the other is minimized.
The first stage in this process is to recreate your production environment in a development environment. This involves recreating all of the integrations your production system has on the development system. Does your production system tie in with a website? Your development system will also need to tie in. In order to accomplish this, you may need to duplicate your website entirely so that you can safely experiment with the development system. You will also need to make sure you do this for any other servers, custom scripts, etc that you are using with/on your production system. Anything that your particular migration script is not going to pull over for you, you will need to recreate yourself first. This will vary greatly depending on which systems you are migrating from and to, so you will want to be sure that you are familiar with what the script you're going to use was designed to do.
To complete the process of reproducing your production environment, you will next run the migration script itself, bringing your production data into your development environment. You are not yet ready to switch systems completely: this is a test migration. The goal is to bring real data into the system so that you can run realistic tests on the development system. The more thoroughly you test, the better. Be sure that all the integrations you have built are functioning as they should.
The goal of testing is to find potential problems of two kinds: problems originating with your productions system and problems originating with your development system. Because your development system isn't an exact copy of your production environment, it's possible that factors in this environment may cause conflicts or problems with the data that would not exist on your production server. You will need to decide whether these issues are best resolved by making changes to the actual development environment itself, or by adjusting the data in your production environment. For example, your development system may have a uniqueness constraint for certain values that your production system lacks.
After making these adjustments, you will want to run a new set of tests to make sure that the changes you made did not create additional problems. It is a good idea to repeat this process until you are satisfied with the test results.
At this point you now have a development system that you can be confident should be able to move into production without too much (or any) trouble. Now you'll need to plan the process of actually switching the development system from testing to live. One of the important things to consider is how you will notify your clients of potential downtime. While this should be a very short period of time it is still a good idea to let your clients know what's coming. When planning the date and time of the cut-over, you may want to think about what time of day would have the least impact on your clients, or when a fiscal or reporting cycle ends, as this will save you the trouble of having to aggregate data for reports later.
How you handle the actual cut-over itself will depend again on which systems you're migrating. Generally, you will run the migration script a final time, take down the public access points for your production server, and replace these with access points for your development server. This now becomes your new production server. It is also a good idea to keep your old production system up and accessible by you for record keeping purposes. You may need to access data still stored there that was not moved to the new system.