Data Migration Process by 1Digital®
Click the steps below to learn more…
1. GETTING ACCESS & EVALUATING DATA
GETTING ACCESS
The first thing we’ll need to do as part of any migration process is to acquire access to the data we’ll be moving. Depending on the project, the platform, and a number of variables, this access can come in a few different shapes and sizes. Here are the most common transfer types and what we’ll need to access your data.
API: API transfer is the most reliable but least versatile method of transferring data from one platform to another. An API is a series of functions which allows data to transmit between multiple applications. If both the platform you’re moving from, and the platform you’re moving to have open APIs, we can move the data through an API connection. In order to do this, we will need full access to both your current store and the account in the platform you’re hoping to move to.
CSV: CSV transfer is the most versatile but least reliable method of transfer. A CSV is simply a spreadsheet with your data inside it. Since it is so simple it can be uploaded to any system, but just because a piece of data is in the CSV sheet, does not mean it necessarily knows where to land in the new system. CSV transfers often need more manipulation of the data after the fact. For this type of migration, we will need the CSV sheets for each type of data you plan to transfer.
Database: Some eCommerce stores keep their data outside of their eCommerce platform in an external database, such as an ERP. When this is the case we will usually need either an API connection or a CSV eventually. Initially, we will need complete access to your database and to your account on your new platform in order to connect them.
EVALUATING YOUR DATA
Once we have access to your data we’ll need to do an initial evaluation to identify any reason that the data, in the format it’s in, would not be able to sync with the new platform. For example, one platform may allow duplicate product names while the other may not, or one platform may save customer group information while another may not. When we see these discrepancies we’ll point them out. It’s best to get as many of them fixed before the data goes into the new store. The more of these that we’re able to catch in the initial evaluation the less time you’ll need to spend making adjustments to your data in the new platform.
With any data migration, not everything will automatically go in perfectly every time. We get as much of that out of the way as possible with our initial evaluation, but we have two rounds of QA coming later in this process to check and double-check where things have ended up.
OUR MIGRATION PROCESS
2. INITIAL DATA TRANSFER
The first data transfer will get the vast majority of your data into your new platform. If design and development are part of your project, our data migration scripts will run concurrently with that work. This helps to save time later in the project. The bulk of the data migration work happens during this phase, but little is required from you in the way of back and forth while our migration scripts are running. Once the initial batch of data is in your new eCommerce store we can begin the more intensive work of checking the data migration and making adjustments.
Next Step3. FRONT-END DATA ALIGNMENT TESTING
After the Initial Data Transfer, we can begin evaluating where all that data has populated on your new platform. If you have design and development as part of your project, that will mean transferring your new design off of our sandbox and into your account as soon as it’s ready. We’ll be able to see where information from the raw data is showing up in the new design, and make any corrections if we need to. This can happen concurrently with the design and development QA period, and while we’re building the new site’s responsive design.
Each site, and each data migration, will be slightly different. Generally, you’ll want to check things like prices displaying correctly, products in the correct categories, details or specification tabs, and anything that has to do with the location of your data on the site’s frontend. We try to get as much of this out of the way as possible with the initial data evaluation, but no matter how similar the two platforms are, every migration will require some reorganization when you finally see how the data populates.
At this point we will also ask you to approve the email blast that will be going out to your customers, to let them know that their account information has changed. You’re welcome to add whatever message to the email template that you would like to send to your customers about the transition. This email will be sent out at the very end of the project, but we like to make sure the copy is approved well beforehand.
Important to Note: This is one of the steps where projects can be delayed if communication does not happen in a timely manner. In order to facilitate this, we use a ticketing system for all issues and bugs that helps us keep track of all outstanding items. Your project manager will help you learn how to submit Testing tickets through our project management system. Please use this system and approve or give comments on fixes promptly in order to move through this phase without causing delays to the rest of the project.
Next Step4. RESYNC
In the time since your initial data transfer was performed, your store has been live. That means you’ve been taking new orders, signing up new customers, and possibly changing inventory all the time we’ve been working on this migration. In order to make sure that your new site launches with the most up to date data possible, we perform a resync just before the new store is ready to launch. This takes all the changes made since the initial data transfer and updates them in the new store’s data set.
As soon as the resync begins we ask that you freeze changes to your store. We refer to this as the freeze period. Only one resync is included as part of your data migration, and we want to minimize the gaps between the old store and the new store when the launch happens. Of course, you may still take on new customers or orders during the few days between the resync and the launch of the new site. We recommend that our clients keep track of these in a spreadsheet during the freeze period. This way we can manually upload those changes once the freeze period ends and the store is launched.
Next Step5. FRONT-END ALIGNMENT TESTING—RESYNC
The vast majority of QA and testing of the data migration will have been done after the initial data transfer. However, there is still the possibility that a change to the data that comes in with the resync could have an unforeseen effect. For this reason, we like to do a second short QA period after the resync happens. Because this is during your freeze period we recommend that this secondary check should not take more than 1-2 business days. A delay in this phase will mean a delay in launch and a wider gap in the data between the old store and new. Please enter and approve tickets promptly during this phase. If any unforeseen issue should require that we postpone the launch, please discuss an adjustment to the timeline with your project manager.
Next Step6. LAUNCH
The launch phase is intensive for any project and it is made even more intricate by data migration. We offer a variety of services directly related to migrating to a new platform. Some come with every data migration and some are additional that can support you after the launch. Please refer to the launch section of your proposal to see which of these services are included as part of your launch.
Password Reset Email Blast: As mentioned in the Frontend Alignment Testing phase, we will be sending an email to the registered customers we migrated alerting them that their password will need to be reset on the new store. For this, we’ll need access to the email service of your choice as well as the approved copy for that message. This email will be sent as soon as the new store has finished domain propagation and launched.
301 Redirects: We recommend 301 redirects as a best practice in any data migration. When a store moves to a new platform, it’s URLs will change its structure, even if the domain remains the same. A 301 redirect submits these new URLs to Google to let them know to associate the domain authority they required for your old site with these new URLs. The 301 redirect sheet is submitted to Google directly after launch, but it will not go into effect until Google re-crawls the site.
Google Search Console Support: Even when a 301 redirect is done, Google may have issues crawling your new site on its new system that you may not be aware of. As part of this support, we monitor your Google Search Console for a few weeks after launch to see if any such issues arise. If they do, we can tell you if you need to address them and what fixes are appropriate.
After the site is launched, you’ll have a free support period during which we can still monitor the data and fix issues if they arise. After that support period closes, you’ll have access to our support retainer program for continuous updates, changes, and fixes over the lifetime of your site.
Data migration is intricate and sometimes stressful but in the end, it’s worth it. Whatever your reason for wanting to change your eCommerce platform is, we’re excited to help you get there as quickly and easily as possible, with all your data fitting into the new store like Lego bricks clicking into place.
CloseEVERY MIGRATION IS DIFFERENT
While the process detailed on this page and created by 1Digital is the general and most common procedure when it comes to platform migration projects, it is also not a blanket statement that forces all migrations towards only one specific path. Just as every website is different and every online merchant is different, every migration project differs in more than one way when compared to a different migration. Each unique project typically deviates from the standard process in some way, as data is always structured in unique methods, functionality requirements differ from one site to another, and particular obstacles require individual and custom solutions. 1Digital’s “migration process” chronicles the general path we intend to implement, however, it is always important to keep in mind that 1Digital will custom tailor your project specifically for your transition.
WHY 1DIGITAL® MIGRATION?
1Digital® has migrated hundreds of stores from old outdated platforms to new eCommerce platforms. The difference in eCommerce platforms can be night and day. We’ve helped migrate clients from outdated Yahoo carts to BigCommerce or Magento, and we’ve seen 10x improvements! From usability to SEO, client engagement, e.g. You can’t afford not to move! Let 1Digital® help migrate your precious data from your old shopping cart to a new one we’ll pick together!