Transcript

Tony Shaheen, DRB^® Product Marketing Manager:  All right, let's go ahead and get this kicked off. Thanks everyone for joining the "Data Migration and How To Get It Right" webinar. Start off here, we want to give you a couple housekeeping items. We're going to send out a recording. We're going to send out any of the Q and As. Give us a few days after here to get everything tightened up. If you're having any technical difficulties, you should be able to exit out, reopen it up, and it should give you some options where you can see the Q and A tab, and that Q and A tab, you're going to be able to ask us questions live and at the end. And then you'll also be able to ask any technical questions.

So if you're having technical difficulties, you can go ahead and put a question in there, whether it's audio, so we have some folks here monitoring that. And again, we are going to take, and we're going to send out the recording, and we'll send out a summary of the Q and A. So any questions asked we'll summarize those as well as the answers so that anyone on the call or who has missed can follow up with those. So I'm Tony Shaheen, I'm the Product Marketing Manager here at DRB. Focusing on Patheon, which is what we're going to be talking about with the data migration in here and how to get from another point of sale to Patheon. And this is Mike Erickson, he's our Senior Product Architect. He's been an integral part of the data migration process since 2021, and he is been at DRB since 2007. I'm going to let Mike take a minute here to introduce himself, and explain why DRB is one of the leaders of point of sale a lot of data migration.

Mike Erickson, DRB^® Senior Product Architect: Thanks, Tony. Like you mentioned, I'm Mike Erickson, Senior Product Architect here at DRB Systems. Been in the industry for about 15 years. Started off answering phone calls and supporting our customers, and have moved into evermore technical positions. Most recently, I've been in charge of the data migration effort here at DRB Systems to really enhance our offerings and improve the process for our customers, as well as kind of meet the industry need. To that point, you know, we've seen incredible demand across the industry over the last couple years that's really shown a lot of consolidation and a lot of sites that want to go over to one point of sales system or they, you know, they're acquiring other sites and they want to bring them under the umbrella.

And because of that, we've really looked at how we approach data migrations. So when we started migrations, we're doing a handful a year. This year I did some math and we're well over 500, so that's fantastic from that aspect. But to get there, we've stood up a team that's dedicated strictly to doing data migrations. You know, they know the process in and out from a host of different point of sale providers. And on top of that, you know, the work's never done. We want to continue improving our processes.

Tony: Awesome. So I know we call it our data migration, but some folks here may not know exactly what that means. So, you know, as we're trying to get a better understanding of what it is and obviously how it's going to work with Patheon, can you give us a better idea of what is data migration?

Mike: That's a good call out, so data migration means very high level, taking information from one system and moving it to another. In our, you know, in our terminology, data migration to DRB Systems is moving customer plan data, and that is, you know, recurring customer monthly plan data as well as non-recurring customer time-based plan data. And in some cases prepaid data, you know, gift cards, units, things like that, from one point-of-sale system to another point-of-sale system. We have processes for that data migration that involve not only going from SiteWatch to Patheon, but other major point-of-sale systems to Patheon, and other major point-of-sale systems to SiteWatch and Washify.

Tony: So the items that you just mentioned, those sounded like a lot of the configuration. I know people spend a lot of time, you know, if they had a point-of-sale before this, building up their customer base and collecting their data. One thing that I know is super important is when we get that token data from a credit card to recharge, does that include that? Are we able to bring that over or is that something that a customer has to start over from the beginning with?

Mike: Oh, absolutely, yes, in most cases we are able to bring over the credit card data. It does depend on the point-of-sale system and the credit card processor that you're moving from and going to. But in most cases nowadays, credit card processors are using what's called a tokenized system, the token, you can kind of think of it like a reference number that points back to a credit card number, but it doesn't mean anything to anybody else, then the, I'm sorry, then the payment provider that issued the token. So because it's just a reference number and it's not useful for anyone else, they are able to take that reference number and decrypt it back into the raw credit card data.

And from there, the original payment provider can issue that over to a new payment provider who then retakes that data, puts it back in the right format and sends it as part of the transfer. So absolutely, data migrations can include credit card data, you know, we pull in the old processor and new processor as part of that conversion. And I will say, because we're thorough, pulling in more parties, more individuals, it can add a little bit of time, but we do help manage that process.

Tony: One question on that, so you said processors old and new, DRB uses a few different processors and I'm sure other point-of-sales use different processors. Does it have to be one of the processors that DRB uses today to bring that data over? Or is there, do we have ways to work with other processors?

Mike: We have ways to work with other processors. So for instance, if it's a point-of-sale that does not use one of our integrated payment providers, we're able to work with that point-of-sale system and that payment processor to extract that data out and move it over to one of the DRB approved payment processors.

Tony: Got it, so there's wiggle room. It doesn't have to be someone we use. Okay, alright, good. So I've seen a few more people join, just want to reiterate, if you're joining a little late, no problem, we'll be sending this recording out as well as any questions that are being asked. We do have time for Q and A at the end, but just a reminder, if we're talking about something and you want to ask a question, feel free to pop it in the Q and A button, and we'll do our best to make sure we can answer that.

Anything that we don't answer on this call, we'll be sure to answer and then send that out at the end. And like I said, to give us a few days afterwards. Here we go. So we know a lot here, and I think we're going to talk a little bit more about our process, but from a wash owner or operator's perspective, what kind of preparation and time commitment is required on their part to ensure that the switch to Patheon is successful?

Mike: Well, the time commitment can vary, but we do want customer participation in this process because it boils down to, you know, we're the experts in moving data back and forth, but there are certain things that our team can't handle. You know, for instance, we're not able to sign any contracts with old processors or new processors to facilitate the data transfer, or any agreements or things like that.

But we do bring the customer along that process with us so that they're involved in the communication between all parties and they're aware of what, you know, what state we're in and where we're at. To that point and probably a really good call out is, you know, a site owner can point somebody from their side to be that product or that process champion for them, that single point of contact that if there's a question, concern, or really anything that we need to get data for, we're able to go to that person and ask questions.

And even if they don't have all the answers, you know, that will be the contact on the wash side to then go and ask questions of other folks and kind of collect that information. Not only assigning that project leader or champion, if you will, you know, can't recommend enough, be responsive on communications. Oftentimes early delays in the process can compound the timeline later on just due to, you know, delays in process or delays in getting signed forms back or things like that. So make sure you're responsive on communications and that you're paying attention on the email chain back and forth.

And if there's any time that we specifically need to have a question answered of a customer, we do call that you know, person out or we'll have a phone call conversation with 'em to explain exactly what it is and why it's needed, and how to go forth from there. I'd also recommend, avoid large change configurations to your plans in the lead up to the migration. And what I mean there is, you know, because we're trying to move data for one point of sale to another, we really want to make sure that things have stabilized somewhat so that, you know, there's no major changes that are coming into the data stream as we're trying to pull that over.

But by the same token, you can look at consolidating data in Patheon. Something that we see quite a bit from customers is, you know, over the years they might have four different wash tiers, but as time's gone on, they've run different promotions. They may have added 4, 5, 6, 7 additional plans. So, you know, now they might be up to 10 different arm plans or recurring plans. And after the promotions, they've mostly stabilized on that same four pricing structure as what the original plans were.

So as you look at moving over to new point-of-sale system, it's important to look at your plans and say, "Do I need all 10 of these plans? Do they do something different? Is there a pricing consideration that we have to be aware of?" Or can they be, you know, simplified as you move over into that new point-of-sale system? Kind of a good time for some housekeeping. From the, you know, from the day of conversion, you know, after we move over to new point-of-sale system, you know, we're resetting up configuration, or we're re-linking, or adding new washes.

So I would recommend the morning after a conversion, you know, as you start to bring up the site for the day, you know, have an additional staff member, or maybe have staff there early, you know, just run through each of the washes, you know, run through the workflows on the kiosk and the cashier stations, just to ensure that, you know, everything's functional, there's no, you know, receipt printer that isn't printing.

And we can obviously address those issues if they come up. And then for a week or two after the conversion, you may want to station somebody at your pay stations if you have them, just to answer questions of folks if they come up and they're used to how an old pay station looked versus the new pay station or, you know, for instance, and we'll get into this in a second, but if, you know, if they are a customer who was not able to get a card data processed over just to explain to the customer, "Yeah, please update your card on file so that you can continue in your plan."

Tony: So I have a question, you mentioned that someone on site should be the contact.

Tony: We deal with with customers of all sizes from one site to hundreds of sites. I know not all of our customers have, you know, full-blown IT teams or full-blown data teams and you know, many are just kind of, they're business owners, so they might not be into the, they might be into data, but maybe not the backend data or the database. How knowledgeable does the person need to be on this type of stuff or, you know, to make sure this is successful?

Mike: Oh, they don't need to be an IT expert by any means. Really what we're looking for, for somebody to be that project, you know, touchpoint, that project lead is someone who knows the business, knows, you know, the washes and the operations side and, you know, can answer questions that we have, or go and find the answers for us if, you know, if there is a question that comes up. You know, really to be that bridge between our two businesses.

Tony: Cool. So really it's somebody who's going to be onsite access, can communicate with maybe the processor, able to communicate with us, you know, able to talk on the phone, answer questions, go hunt down that information. It's kind of someone who's really active in the business, really.

Mike: Absolutely active in the business, they don't have to be on site, but we would ask that they'd be able to contact the person on site should that be necessary.

Tony: Okay, okay, cool. All right. So I know one really big concern when you're changing point-of-sale, you know, provider and credit card processor is data loss. And I mentioned it earlier, you work very hard to build your business, you have a point-of-sale that, you know, maybe you're ready to move over to something like Patheon, it's a little more advanced, but you've worked all this time to build your customer base, to set up your washes, things like that, you know, can you explain how the process works today? And I know that we've done some innovating with Patheon, and you know, how are we doing it differently with Patheon so that it's a better experience and it's, you know, going to mitigate that data loss?

Mike: Absolutely, you know, when passes became a thing in the industry, it really revolutionized how people monetize their sites. And we take that seriously, you know, these customers are not just folks that are getting a wash, but they represent a huge portion of most car wash operators, you know, business. So I'll hit on our legacy, what I call the legacy process. You know, and this is true for most point-of-sales out there. And I'm going to hit on very high level, won't go into too greater detail, but these are all the most important points. So the legacy process starts with extracting data out of the prior point of sales system, 6/8 weeks in advance of the actual conversion over to new point-of-sale.

From there we verify the data integrity and that we have what we need to begin the transfer, and we kick off the card data transfer process with the new and old processor. And what that means is we send a list of those reference numbers to the old processor and asked them, "Here's the list of reference numbers, can you please extract this data and send to the new processor?" And all that means is they then take on the responsibility of taking the reference number and extracting it that raw credit card data, and securely sending it over to the new card processor.

From there, the new processor will take that data and ingest it into their system, essentially run it through their tokenization process and provide back to DRB Systems, the conversion file, "Hey, here's the old token and the new token." We then ask for a new backup. And mind you, this all takes, you know, generally four to six weeks to complete. So by this point the data's kind of stale.

So we ask for another backup of the site point-of-sale systems database. What that does for us is it allows us to see that data that's changed and match it up with the card data we got back from the new card processor. Today, you know, because I said that starts weeks in advance, we try to get that last backup, the most recent, pretty close to the actual conversion timeline. So let's say you convert on August 1st, 2023, we would want that new backup about a week beforehand just to make sure it's as current as possible while allowing for enough time to work on the information and convert it over to the right formats.

But because the timeline started weeks in advance, you know, there is a blackout period, and what that means is anybody who signs up for a plan after the first extraction, we'll have their data because we'll have it in the second extract that we get, but we won't have their credit card data. So this leads to what we call a blackout period.

Now, normally in the system, you know, you import that customer in, and the system then prompts them for a credit card. And that's what I mentioned earlier about having somebody at the pay stations to just help the customers through. On average it's a pretty small number comparatively across the customer base, depending on timing and how extensive promotions are for arm plans generally see that number to be about 5 to 15% of the customers moved over, will need to update their card data after the fact. So that's kind of the legacy process in a nutshell.

Patheon has allowed us to really reimagine what this looks like, in a way that really helps to eliminate that blackout period. So I talked before about, you know, we're pulling data six to eight weeks in advance and we're verifying this, that, and the other. Patheon allows us to essentially convert first to Patheon. So we would ask for that conversion information about a week before the conversion Patheon, minimizing or drastically reducing the blackout period.

From there we pull that data into Patheon, and allow the site to convert over all their hardware as needed. Patheon then handles all new card sales, promotions, things like that, and allows the customer to use their plan. In the meantime, the old point-of-sale would continue to recharge those customers for however long it will take to get the card data transferred over from the old processor to new.

So that four to six weeks that we're looking at before in the legacy process, doesn't have to take place before the conversion. It can now take place after the conversion to Patheon, which really allows that blackout period to be reduced. Because of this, you know, we're anticipating a much smaller number of customers who will need to update their card.

Tony: So what about reporting or education? How does a, you know, how would a customer know who's in a conversion? What's going on during this process?

Mike: Reporting is always a tough subject when you come to a data transfer or data migration, just because you're looking at midstream data, and sometimes you have to look in the old system and sometimes you have to look in the new point-of-sale system. You know, that's another area we're taking a really deep look at in Patheon and we're creating dashboards now that will give the customer the total number of plans migrated per site, any churn rate on those migrated plans, you know, are you seeing a churn after the migration that's higher than before the migration, okay, why is that? You know, it allows the customer to really drill down into their data, and get a much better understanding and just allows you to get there faster and understand your customers a bit better.

Tony: All right, and so with the new Patheon process, by reducing that blackout period, we should see a lower amount of churn, and able to really increase revenue because that blackout period caused us to not capture the token, correct?

Mike: Correct, so in that instance where a customer signed up, and then did not come into the wash after the conversion, their data would, you know, they would be removed from the system after so long because they did not update their card. Patheon really strips that problem out and gets rid of it.

Tony: Got it, okay. Okay. So I think we've covered most everything. So at the end of the day, it sounds like the ideal situation is we look to have someone at the site who is prompt, able to respond, in contact with us, able to go hunt down the information we need. A lot of the stuff here, it seems there's a little bit behind the scenes, right? So what we're doing is we're building the railways, I think, to transport the data and keep our customers informed, especially with those reports, we're helping 'em reduce churn, and increase some of that revenue with removing that blackout period.

Oh, it looks like I actually have a question right here, let me see what that is. This one here is you mentioned a person from DRB would be assigned to my wash for, oh, so we talked about the person at the site, we didn't talk about the DRB person who'd be reaching out, what are they going to be doing, what's their responsibility?

Mike: So we actually have two people on DRB that will be assigned. We have what we call the project coordinator, who's assigned to essentially assist with the project on a whole, you know, looking at shipments, making sure things are getting to the right place at the right time, and really being that single point of contact for the transition process itself. From the data migration side, we have a team dedicated, we call it the data migration team, and we essentially assign one member of that team to work on that project.

And we try in some cases, you know, if a customer has multiple sites that they want to migrate over, and you know, if we're able to, we do assign that same person to those projects as well because they'll have gained familiarity and they'll gain, you know, rapport with the customer project lead at that point. So we've got two folks that would be assigned to this, you know, one from the more admin oriented side of things with the project coordinator, and one from the deep technical process from the data migration team.

Tony: Let me take a quick note there. No, that makes complete sense. So another question that actually just popped in, which I think at this point just to make sure, is there anything else that you wanted to cover before I start answering some of these questions that are popping in?

Mike: No, I don't think there's anything I want to cover more, the process in general, the data migration, if you look at it at a very high level, it's pretty straightforward. It's where you start diving down to the actual process, and the data polls, and things like that, it gets a little bit more, you know, in depth, a little bit more complicated, and those are the areas that we really step in and try to help with.

Tony: And so that makes a lot of sense. And the one question that just popped up here, which I might try to break it into two depending on how you answer it, is multi-site, if I have multiple sites, how does the data migration work?

Mike: It all depends on the customer's project plan, what they would like to do. We have done conversions where they want to convert one site and then wait a couple weeks and then convert the next site. That's possible. There are other cases, where they want to try to go and flip of a switch and convert all say 3/4 sites at once. We can certainly work with that as well. It just depends on, you know, the customer and really what the ask is and what's best in those cases.

Tony: So it's not necessarily a site by site conversion, right? It's kind of, it's a one, you may have to analyze if they have multiple sites, but once that comes in, that's kind of a one time import right? To Patheon, there's not like a multi-site import, there's not going to be a delay because we have multiple sites.

Mike: Not usually, no. We will handle it as one site at a time, but the process itself is not that in depth once we get to the point of actually importing the data.

Tony: So that doesn't really add any additional time. So if I have, you know, 10 sites versus 3, it's not really going to take much more time for the 10, if I had 10 sites.

Mike: Correct.

Tony: Got it. So you mentioned one thing which was you have someone who's going to make sure that the hardware is plugged in. Where does the data migration connect or fall into place when you look at the hardware? So if you're coming over from a new point-of-sale, there's some new hardware that's going to be getting put in maybe the appliance or the point-of-sale itself. Where does that data migration fit into that whole process?

Mike: With Patheon, it's actually kind of outside of that process. If it needs to be, because it's a hybrid cloud solution, Patheon's data processing, a good chunk of it actually exists up in the cloud. So we can do the import before the site is live on Patheon and if we're coming from another point-of-sale system, we're able to delay that data actually taking effect until the date in which we expect to go live on Patheon.

Tony: Okay, got it, got it. Another question is, if I decide to move to Patheon and I don't want to go through the process of migrating my data, what does that mean? if I don't want the downtime or any of that?

Mike: So we've got a couple options there, and it depends on what data that you may not want to go through the migration for. So we've seen some customers decide that they do not want to go with the credit card portion of the data transfer, but they do want to go with the customer plan part portion. So what we are able to do in that case is extract the customer data out of the old point-of-sale system and import it into Patheon.

From there, because there's no card data available, Patheon will start asking customers as they come in to update their card, we're able to select certain days, dates, I should say, for Patheon to start recharging. So we have a little bit of a time period to allow customers to update their card on file before we start trying to attempt those cards, just to give more time for a more thorough and increased capture rate.

Tony: Got it. There's a couple more here actually, that's good. Thanks, Thanks guys. This one says if I have recharge plans that have members in them, but I want to simplify what my wash offers can you, so can DRB, consolidate members during the migration? So if I have 10 plans and want to consolidate down.

Mike: We absolutely can. A good example and I'll obfuscate a bit for the customer question, but we found that they had Father's day promotions stretching back from 2017, and what they would do is create a new pass plan for every Father's day since 2017. So there was a 2018, 2019, 2020 and so on and so forth. But they were all for the best wash. Well these plans had long since normalized to what the best washes plan price was, which I think was about 30 bucks a month. Well all of those plans don't need to exist going forward.

And in talking with the customer, they agreed that well they're not tracking those anymore, they don't really need to know about 'em, they just had never undertaken the process to move 'em from one plan to another. So as the import process continued, we decided along with the customer, hey, if you don't need these in separate plans for reporting purposes, it will look a lot better, and you'll be able to manage the system better, by just, if you'll excuse the trying of phrase, squishing them down into that one best wash plan.

Tony: Got it, okay. Looks like I might be down to the last question here. Are there any, oh, I see here, are there any performance or downtime constraints with the data migration? So do I have to take the point-of-sale down or my wash down to make this conversion work, and will we see any performance issues if I don't? To take.

Mike: So it depends on the source point-of-sale. So for instance, in some cases we're able to grab a backup that was made prior and use that data. In other cases, we do need to shut the original point-of-sale system down to essentially enable the conversion over to the new point-of-sale system. So it does matter a bit on which system you're going from and you're going to, we do shoot to try to reduce any downtime as much as possible. And for the data transfer portion we do try to shoot for, you know, if there is downtime, try no more than than about four hours, and we do start a bit early in the morning to try to get that before the site really starts running for the day.

Tony: Okay, okay. It doesn't look like I have any more questions here, so give one more second, if anyone has any questions, go ahead and pop those in. If not, you are able to reach back out. So we have sales folks that are in your area so any questions you would be able to reach out to them and we could set up more time, and provide more information as needed. But outside of that, I appreciate your time and we thank you for joining the data webinar and how to get it right. So appreciate your time and have a good day, thank you.