CHRIS: Typically, for most of our clients, based on how they're operating their business, we recommend bringing over most of the data. Anything that you can remove from the necessity to migrate is certainly going to be beneficial in many cases. A lot of times there's information that just isn't very valuable. It may not have a lot of credibility to the data, or it just might be old data. In that scenario, it would be possible to get an archived copy and have a nice backup that's available, but basically not force that data on the new system and on the users going forward.
For example, there may be very old oneline auctions that you want to archive for recordkeeping, but maybe you just need to pull the most recent auctions from the last 24 months or 36 months, and that's totally fine. We can do that.
One of the other things that might be necessary is keeping detailed records for the users so that they can access each of the pieces of data. One thing we've done before, in that scenario, is come up with a timeline of what data we're going to pull. Usually 12, 24, 36 months is a reasonable look-back period. But the team will also provide the ability to request more data, so they can make a request and then that can be fulfilled in a manual process because the frequency would be low.
If you don't think the frequency would be low, you can even do things like sending out a survey to the existing customers of your eCommerce auction platform and saying, “Hey, this is what we're planning on. We're planning on a major upgrade to the site, we're looking for feedback from some of our high-frequency users and we wanted to get your thoughts on how far back is reasonable and if it's going to have a big impact on the timeline to take things live. What is your opinion? Should we go ahead and just keep it to 24 months or 12 months and just make it a lot easier to go live with this new site? Or should we go all the way back in time, possibly five, ten, 15 years back with migrating all of the data?” I think most of the time what you'll find is that the end-customer is going to be dependent on more recent data and not so much on deep historical data.
So the other thing that we've seen with the deeper data is—this can also be really useful, at least going back 12 to 24 to 36 months—if the B2B eAuction platform has a nice way of representing the different bids and the timing of the bids and information about people's interaction with the B2B auction sites. This can be used as part of a feedback loop and making sure that we have almost a form of analytic on the site that can be really helpful as a set of data for machine learning or AI training within the application.
You're just going to want to think about not only getting the full set of data for a time period, but also thinking ahead about things like, “Do you want historical data to train an AI or to train the machine learning so that it can better perform within the site.”
Outside of that, I would say the other big pieces of data that make a lot of sense to bring over includes category/subcategory, associations with auctions to those categories/subcategories, any taxonomy with tags, and overall structure to the application reviews. [Also bring over] reviews of buyers and sellers and frankly, the list goes on. But ultimately being able to pull all of that historical data tends to be important for the community and being able to pull it over accurately.
At the end of the day, we do this process in several different ways. Ultimately, the adaptive ability of the development team that you're working with on your new platform is going to be very important. So they're going to need to be able to work with some of these different systems that they may not be used to, they may not specialize in, and be able to adapt and get the data that they need.
So, Ron, we work a lot with different APIs, but we'll also, if the APIs aren't available, or they just don't cover every single endpoint that we would need to pool all of the old data, then we'll go directly to the data persistence layer, which is usually a database. This works really well overall to be able to access everything and bring all the data over to the new eCommerce auction platform.