Migration Guide

Learn how the ObjectRocket Migration process works, and what to expect moving forward with us!

Data Preparation

The initial stage is where we gather all the required information from the source server, and the destination environment is prepared for the incoming data. Information gathered would include the following:

  • The location of the data (Cloud Provider, Data Center, Current Architecture, etc)
  • Programming languages in use, as well as any frameworks that go with them
  • Current driver version, and connection configurations
  • How the application is modeled, and discuss any access patterns
  • Projected data growth, and size
  • Identifying current pain points, and discussing proposed solutions
  • Downtime considerations, and maintenance schedules

This information will assist our team in choosing the right environment that suits the customers needs. Knowing the ins and outs of the application will allow us to eliminate any scalability concerns that might arise.


During this phase we work to setup all networking access and provide any information needed for access. With the environment set up and connectivity tested, we will begin the migration using the methods outlined in the initial plan.


With the migration in-progress, we will work together on testing the applications ability to access the data as well as ensure that all servers have been added to the ACL’s (Access Control List) for the instance. ACL’s service as a list of machines that are allowed to access this data (all other machines will be disallowed).


During a scheduled maintenance period, or off-peak business hours, the connection string within the application will be updated to point to our infrastructure.


Once the connection strings have been updated, our team will monitor the instance, and ensure everything is healthy, and running as it should.


As the majority of planning is based around the optimal method for migration, the rollback plan is usually only related to the switchover. Since most of the methods are fairly transparent until that point they can be restarted with little impact. Part of the plan we put together includes making sure the old environment is available in case we need to fall back. Even if this plan is not invoked, we recommend leaving that environment up for at least 48 hours in case you find the need to access it.


This is the final phase. The application is now pointed to the instance hosted on our infrastructure, and everything is considered a success. Our team will offer assistance with any query and index optimizations, scalability concerns, and identify any actionable items that will assist in ensuring data is delivered fast, and at all times.