Oktane19: Migrating Users to Okta - a Piece of Cake!

James: Today, I want to take you on a journey with me today. Don't worry, we're not going to get up, we're not going to go anywhere. This journey's going to occur in our minds, and on this journey you guys have a vision and that vision is your company rolling out Okta. It's implementing API access management, it's implementing lifecycle management, rolling out MFA, and using the reporting and analytics. But how do we get started on this journey? Well to get started, you need to be in Okta, and you need to be in Okta, and all of your customers all need to reside in Okta and that's what we're talking about today; taking users from various different directories and bringing them into Okta so that you can begin that journey, and fulfill that vision of being fully ruled out. And it starts with the identity.

James: When we think about the identity, we have to think about the components of the identity, and really it's broken up into two main components. The first being the profile. So everyone in this room is a customer of something, whether it's your credit card, your mortgage, or your home warranty, and for each one of those systems, we've all went online, fill out a massive registration form with our personal information like our first name, our last name, email, address, phone number, et cetera. All that information that is submitted to that system is our profile.

James: The second component of the identity is the credential. Now for each of those systems, we've all also went online, created a password. Now hopefully it's not "password1234," but if it is, that password is then hashed and stored in a database somewhere despite recent news about plain text passwords.

James: So when we talk about user migration, we're talking about taking those two components, the profile and the credential, and moving that identity from one system on to a completely different system. In this case, we're talking about Okta. And that leads us into the variables you want to consider.

James: So when we start thinking about this migration, the first thing you want to think about is where do your users currently live today. Do they live in active directory? Do they live in LDAP? Do they live in some database that we've created 15 years ago and that we're still using today? Or do they live in another IDP? Regardless of where they're stored, the technology used to store them in that old entity is going to drive how we pull them out, and it's going to drive how we get them into Okta.

James: The second variable, the hot topic of today's general session, is digital transformation. And really at the core of digital transformation is customer experience, which is our second variable. When you migrate your users or your customers, how do you want them to experience that migration? Does anybody here want to reset 12 million passwords for customers? I didn't think so. When we migrated MLB, we didn't do any of that. We migrated profiles, we migrated credentials. Why? Because the customers don't want to know about your migration. They don't care that you moved from one entity to the other entity. They just want to log in and get access to their stuff. And that's why customer experience is so important. Now with Okta, you can make that really, really simple using the sign-in widget, or you can take all of Okta and put it behind your current sign-in page if you wanted to.

James: And encompassing all of this is security. Right? We're going to be taking personal data off of that old system and sending it into Okta somehow, some way. When we do that, we need to make sure that's the cure. And that doesn't just mean using TLS and SSL to get the data up there, it means securing the output data. Like who has access to that data, where does that data live, and how is it transmitted and stored. Once your company has had time to evaluate these variables and understand any risk associated with it or how you actually want to do it, or what technology you're currently using and how it's going to affect your migration, then you can take a look at some of the different migration methods.

James: Here at Okta, over the past several years, our professional services team have worked with thousands of customers and migrated millions of identities into the Okta identity platform. And in that time, what we've learned is that migrations really fall into three main buckets; those being a bulk import, some form of just in time, or JIT, or an existing directory. Let's take a look at those methods.

James: With an existing directory, a small agent is installed on your system, that agent queries your user store, based on the results fed back from the query, you can send those in to Okta and using an import hook, you can actually manipulate that data. You can pull data from the third-party database and combine it into that profile, you can do username conflict resolution, you can build usernames, you can correct data, you can combine data, you can do whatever you want that import hook. Once you're done with that data, you send it back into Okta and those users live in Okta. And you'll notice here directory integration only brings in the profile. Right? There's no credential and that's because a credential still lives on those old systems, whether they're active directory or LDAP. So in this scenario, this is a perfect scenario for a hybrid solution. So in this world, you can live in Okta but also keep your old on-premise identities if needed.

James: Our next method, it's not an integration like directory integrations is, it truly is a methodology, and that's JIT, or Just In Time. With JIT, your users will log in to Okta for the first time and once they log in, a back-end process will kick off to validate that user. And once the user is determined to be a valid user, their account gets created on demand in Okta. In this scenario, you get to migrate only active accounts. All right? So that means you don't need to migrate tens and thousands of old accounts that have been sitting there for years, and you have no idea whether they're used or not. Using JIT, you can just migrate in the active accounts and have a clean data set. And JIT also works in the directory integration world as well as federations. You'll notice, too, for federation, it only brings in the profile and that's because the credential still lives with that other IDP or that federated identity. So again, another hybrid scenario good for partner use cases, bringing in partners and what not.

James: And third is a bulk import. With a bulk import, we're taking the output of some other entity, some other system, and we're using the Okta user's API to programmatically add that into Okta. And you'll notice here this brings in the profile and the credential, and that's because the Okta user's API supports hash password objects meaning if you have access to the salt and the hash password, you can bring those directly into Okta. This is a great scenario for those day-one cut-overs. Day one, you want everyone to use Okta, you do a bulk import ... sorry. You do a bulk import and everybody's in the system active with their profile and their password on day one.

James: Now our next speaker, not too long ago he was in your shoes. He attended Oktane, he went through the POC process, his company evaluated all the migration variables, they evaluated all the migration methods, and ultimately they came to a decision and he's here with us today to share that decision. Please help me welcome to the stage Rocco Martin with Umpqua Bank.

Rocco Martin: Hi, everybody. So I'm wearing this silly hat because Ally Cozel made me do it. So now I don't have to wear it anymore. They gave me a very nice honor last night of the builder award, and with that came a blue hat and she said, "you must wear it today." So now I have evidence that I wore it today, thank you.

Rocco Martin: So we are with Umpqua Bank, and Umpqua Bank is a midsize bank in the West Coast, western states, Pacific time zone. We even have a little finger in Idaho because they're a little tiny bit of Idaho is in the Pacific time zone, so it's important we get everything. And we have a need to take a new application and bring it in to our customers, and make it easy for our customers to use and keep with the direction that we want to move our customers towards, and I'll get to that in a second.

Rocco Martin: So who are we? Umpqua Bank started off ... Okay, I have do to this pun, I'm obligated, we have our roots in logging and we started off with a six-person company to cash paychecks for the logging industry in Canyonville, and from there we grew and grew and grew to the size we are now, but we never lost the initial ideal of providing a service to our customers and being there for customers that wouldn't have another avenue. Because in the logging industry, there weren't a lot of places to cash your paycheck.

Rocco Martin: Around 2005, 2006, our CEO at the time, Ray Davis, realized that the branches in banks were boring and not very useful, they're stodgy. So he worked with places likes Neiman Marcus and Nordstrom to come in and train our people, make them universal associates so that if you got somebody, they could help you no matter what. It was never please wait and I'll hand you off to the next person because I only deal with X. And also turn them more into community centers so you can have ... sorry. You can have conference rooms that you can check out, anyone in the community, you don't even have to be a customer. We even have yoga classes in some of our branches. So it truly is a community environment. We even have some areas where we showcase local boutique industries so that when you're coming in to our branches to get your coffee or on Friday your cookies, that you can also see some the wares of the companies that might just be around the block from that branch.

Rocco Martin: That shows that we want to actually be there for our customers and perspective customers as part of the community, and providing services, not some stodgy old thing.

Rocco Martin: So one thing that we wanted to do was move into the digital age with that same policy. We wanted to go into the digital world and present an interface that was outreaching and comforting and human. And so we worked with a company that we created called Pivotus Ventures, it's a separate research company because research companies don't work very well under banking regulations, so as a separate company it was able to move fast, fail fast, and innovate. That company has since been purchased by Kony, so it's now a Kony division, but during the whole time of this bringing up to the product, we went through several iterations and we reached a product called Go-To.

Rocco Martin: And Go-To you might say is a chat application and you'd say, well, so what. Everybody has chat, it's Jennifer the AI person that pops up on your screen, or a call center person that you might never see again. Ours is different, of course. We're not using AI, we're not using a call center where you get a different person every time you call. When you sign into Go-To, you get your personal banker, you get to decide who your personal banker is, and in fact press has been calling it the Tinder of banking. Sorry. Because when you first come up, you get to see a range of bankers and you get to see what city they're based in, what their likes and dislikes are, long walks on the beach, also what types of banking they tend to specialize in so if you are worried about funding your child's college or getting ready for retirement, maybe Bob is better than Janice in this case.

Rocco Martin: All right. So let's move on to the sizing. Our numbers right now is we have roughly 200,000 online banking users in the consumer space. Right now we have about 15,000 enrolled in Go-To. Reason this number is so low, sorry, is that we like to go with the crawl, walk, run policy with our applications. And so we're being very slow and careful and methodical because we have to train our customer support people, who are actually the same people that you might meet at the branches, as well as make sure that the software is in good shape. So this is strictly from word of mouth that we have 15,000 users at the moment. This application is using what the development people are calling the app-auth model. That means that the application doesn't know anything about authentication. It's strictly handing off to the browser. So that's nice when you're running your own applications. You don't have to worry about anything. If you are not logged in, you hand it off to the browser and it'll wake you up when the time comes that you've jumped through whatever hoops you have to do for MFA or for enrollment.

Rocco Martin: Let's look at the requirements that our product team came up with when they said you must make Go-To, and you must make it happen. Well, make it work, always. Because we wanted to make this super easy, we have to use the same credentials as online banking which makes sense, right? That's our number one spot for our customers, is that essentially. Even though we do way more than online banking, that's what they see. So we want to present the same credentials. The next thing is when you get in, it must be easy, so provisioning. We must be able to put everything into this new application except for the selecting of the banker. And third, if you're not already an online banking user, this is where we ask as few questions as possible because we don't want to scare you off.

Rocco Martin: So that sounds great, and that's what everybody would want their application to behave like. And of course as the military folks say, no great plan survives the first encounter with the enemy. So our first consideration is our online banker doesn't do that. Our online banking software has its own credential store and doesn't like to share. I have it on the road map for three years from now, but they don't currently support any kind of federation. Next, Go-To needs to hide all this complexity from the user. So if the user has their credentials in Okta or if they have their credentials in our online banking provider, we're not supposed to let Go-To users know or care. And we need it yesterday. So we have an uncooperative current credential store that needs to stay live and not know anything about us. We have a new application that is very flexible but needs to look like it's part of a team and we need to make this happen now.

Rocco Martin: So how do we do this? Well it's not quite as complicated as that. Unless you want to code all the openID connect stuff yourself. And it's also not magic. It's basically this. And if you look at the outer box, the outer box is really nothing more than a traditional openID connect authorization code flow, which you can use the Okta SDKs to hide all the details if you're not concerned about how to make this happen. What we added was the proxy that's inside the identity provider that allows us to provide the custom behavior that lets us serve two masters basically. And we also have to serve the CDN, is the content delivery network, we have to host our own log in and registration pages because at the time, the Okta pages wanted to point to Okta and we needed it to point to our proxy, and a few other small changes, but by and large it's the same as Okta log in pages. And then we implement the OAUTH endpoints, and we become in the best case, just a pass through to Okta.

Rocco Martin: So if you come in and I've seen you before and your credentials are good, you don't even ... we don't have any special logic. We're just forwarding it off to Okta and forwarding it back to you. If we have seen you before but your password is not good, we check with the online banking provider. If it turns out that you went through another channel to change your password, we'll catch that, correct that, and put us back into sync. And then the third flow, which is the primary exception flow that we're talking about today, is the migration case. So we detect that you're not in Okta, you are in the online banking provider, so we pull the profile and the MFA targets out of the online banking provider and then we, Just In Time, add you to Okta and register the MFA targets. In our case, it's voice and SMS, and in our case one really nice thing about the online banking platform as our source is we know that we can trust the profile because it came from our core and the MFA targets because it's constantly challenging the customers for MFA. So we know that all of that is current.

Rocco Martin: What we want to do in the future is work with Okta to use the web hooks and take out the part where we sync out, where the user is in Okta and in our online banking provider, but the passwords don't match. And then the other exceptional flow of the migration that we can have those be separate web hooks, and now we are making our risk and our hosting and our security teams so much happier because they are not thrilled about this picture right now. We don't want to be hosting our own CDN and our own public facing API at this time. We're doing it, but they would much prefer to have us hosting web hooks that are locked down and only accessible by the Okta servers.

Rocco Martin: So let me go back. One thing about openID connect is there is a lot of bouncing around, and a lot of people are really unsettled by all the bouncing around that happens. What you'll find is that it's not really quite so bad as you think. I mean yes, you are going from the device to our proxy, which then talks to Okta, talks to online banking provider, talks back to Okta, bounces back, bounces down to the server, bounces back to Okta, bounces back down to the server and up to the device, and now you're ready to go. So that seems like that would be a horrendous user experience.

Rocco Martin: What I'd like to show you is an example of what it really looks like. So this is a user who exists in online banking but does not exist in Go-To. And they're logging in for the first time. This is where the application goes, you don't have ... I don't know about you so let me send you to the log in page and open a browser. The user starts typing in the credentials and they're relatively good at typing in credentials. And the second they hit done on that, that's when all of the hopping and the magic happens. It goes, authenticates, and now it's already done with that and we're at the server and we're ready to choose our banker. It's really, very painless. And at this point, the user is provisioned and part of both of the worlds and ready to go.

Rocco Martin: And that is ... oops, sorry. And that is our story for Umpqua Bank. Thank you very much for your time. Now I'd like to bring Jo on for how Okta can help out. Thanks.

Jo R.: Hey everyone, I'm Jo Raghunathan from Okta professional services. This was a seamless, wonderful user experience. Now Rocco talked about the use case where they had to maintain the credentials and boot their legacy system and the new Go-To app. But this might not fit all customers. You might have different needs. Quite often, and we've come across in professional services, cases where you have to sunset your existing system before you know, when you're moving on to Okta. So you no longer have access to your current credential store. Everything needs to move over, you sunset, you're ready to go. So everything needs to be in Okta. So how do we achieve that kind of migration model? We do it using our API endpoint, the user's API, and I'm going to talk to you about how to go about it, what are the best practices, and how we in PS can help you with that.

Jo R.: So we call this the bulk import model. And we quite often see this in SIAM customer identity use cases. It could be insurance companies, airlines, hotels. They have millions and millions of users. Right? They want to move everyone to Okta and you could also be restricted by the fact that you don't just want active users in Okta, you want the entire user population in Okta for whatever, it could be your business reasons. So everybody needs to move in to Okta, move in to Okta fast, and credentials need to move in, passwords needs to move in, profiles need to move in, and you need to be ready. So what are some of the considerations here?

Jo R.: So let's talk about each of these. Data cleanup. When we're talking about millions and millions of users, we're talking about legacy systems that went online 20 years ago. You have a lot of data that could be messed up, right? So our customers use this as an opportunity to kind of go through all the attributes, figure out what they want to import into Okta, figure out what's missing, kind of clean that up, how to triage that. So that's a key component before you actually try to import them into Okta. I mention customer identity use cases. Before you could have loyalty IDs like my shopping card or some unique loyalty number. I want to do a lot of pre validation, make sure that's unique, if there's any calculated attributes and things like that. I do all of that in this pre ... we call this the pre validation, the data cleanup, and basically you're getting your data ready to push into Okta.

Jo R.: The other thing is the password syncing. Now in Rocco's case, we sync the passwords on the flight. The password and the profile, it was Just In Time, and we had to maintain the passwords in both systems. And James briefly touched upon it. If your passwords in your existing system are hash and salted using ... I think right now we support SHA1, SHA256, bcrypt, and MD5. So if it's any of these algorithms, you can load these users into Okta via the user's API, and you can import those hash passwords. So if you have that, great. You're ready to go. So we can also sync passwords if you have any of these five. If you don't, it's some other hashing mechanism, you're not able to do that at this point, you could kind of do the profile migration before you go live and then you could just do the credential migration on the fly like how Rocco explained. Right? So it depends really on your use case.

Jo R.: And deltas. So I bring up deltas here because recently we've had these migrations which run into millions of user accounts. While the migration is happening, your existing system doesn't go offline, right? You still have people creating new accounts, you have people changing their passwords, updating profiles. So you want to sync that into Okta, too, before you sunset the existing system. So how we normally have gone about it is we do this huge migration first, and then we run a couple of deltas to make sure you get all the changes into Okta and maybe for a small window of time you stop any changes to your legacy systems, so no more profile updates, password changes. Right? After you've put in the last delta. And at that point you're ready to go. So that's how we've approached bulk import scenarios.

Jo R.: Also, during the bulk import itself, like I said we do it using our users API endpoint and if you're an existing Okta customer, you might have run into rate limit issues. All our endpoints are heavily rate-limited, so during migration, PS will work with you guys and with our operations team to kind of temporarily raise those rate limits so we can get the users in as fast as possible. Right?

Jo R.: So that's a key thing, the rate limits, the performance. Also, as part of our pre validation, we do a lot of testing, right? And it's not there on the slide, but I really want to touch upon it. We want to test with your data and we don't want to test with data in some non-production, old database where the data doesn't resemble what you have in production anymore. We would like to get a subset of your production data obfuscate, whatever we need to obfuscate, and then do our testing and our migration strategy based on that data. Because if the two data sets look nothing like each other, we might be missing some cases and we don't want to do triaging later on after our migration is done. So if our pre validation is good, we've taken care of ... we're working with real data, obfuscated of course. We minimize the failures at the end of our migration process.

Jo R.: So in PS, we've come up with a methodology of how much data we want to test with during our pre validation phase. So there are some numbers, we can share that later on with you, but I think for 500,000 to one million, about 25 percent of your user base, anything over one million, maybe 20 percent. If you're able to get that data obfuscated, tested in our preview environments, that gives you a very good idea of how long the migration is going to take, what are the use cases you need to be aware of, and we can really reduce these failures at the end of migration.

Jo R.: So this is about bulk import. This is one of the three migration methodologies that we have here for you today. So I'd like to invite James back up on stage. Thank you.

James: Wow. Thank you, thanks Jo and Rocco for sharing your story. As you can see, there's several different methods to bring users into Okta. Rocco used JIT, a form of JIT, by building an auth proxy, and Jo talked about how we do bulk imports. So there's several different ways you can bring your users into Okta, and whichever way you decide to do it, we're here to help you. So our professional services and our support team are both here to help you with your migration because they've had the experience over all these past several years, and bringing in all these identities from various different sources.

James: So now, I'd like to invite them back up for an open Q&A session, so can you guys come on up? I have some questions to ask them myself, but feel free if anybody has any questions that come to mind, there'll be some mics going around and we can chat with them.

James: So Rocco, my first question is you guys did this one project, you're migrating over active users as they log in, you have some growth there. What's next for you guys? Are you guys going to do an additional migration, or are you going to roll out more apps? What's next for you guys?

Rocco Martin: Yeah, so well first we have to get this app up to full where we're doing marketing and we're trying to get just as many people on this application as we have in online banking. There's a couple of ways that we're doing this; one is we're looking into avenues to bring online banking into the federated identity space, then that removes a lot of our challenges. Another way is we're, as I mentioned, we're looking at the Okta betas for the registration hooks and for the migration hooks and the failed sign-on hooks so that we can pull ourselves out from the front and be able to take advantage of the scale of hosting that Okta provides. In the future, we'll then take that success and I think we'll stick with the app auth model so that our developers can focus on the core logic of the application, and that we have a consistent log in story for all of our applications, and we have ideas for a few other applications to bring to the public then.

James: Cool. Great. And in regards to user experience, at Umpqua Bank, how important was the user experience? Was it just from the marketing team that want it there, was it from the IT team? How important was it there?

Rocco Martin: Yeah, no, it's critical because again, we want to have security and our security team says there must be certain levels of security, but we also know that the more we expose the security to the end user, the less they like it, so we want to have it hidden under the covers. And so we need to have an experience that really doesn't show that the heavy security is in place, and we are doing this ... actually we did this very similar to what was shown in the session yesterday, where you come on as a perspective customer and we're only going to ask you your name and your email address. And when you get to become a full customer, we'll ask a little bit more to prove that you really are who you say you are because now we have a more vested experience with you, and we need to know more that you are who you say you are, because we're going to start having advice, we're going to start asking about accounts, things like that. So we want to start simple and quick and then grow as our relationship grows.

James: Okay. Great. Thank you. And you had mentioned federation when you first started talking about your migration. Was federation your first approach, and after it didn't work out, how did you come to the second approach? And why was federation your first approach?

Rocco Martin: Well federation's our first approach because we want to get to the point where we are the ones that are providing the log in, that you're logging into Umpqua bank, you're not logging in to online banking or you're not logging into wires, or you're not logging into any of our suite of applications. In the banking, and probably health, industries, you tend to not develop all your own applications. You tend to use vertical apps, and those vertical apps like to be in great silos that don't talk to anybody else. And so trying to provide one log in and a suite of applications in that situation is a challenge.

James: Great. Any questions out there in the crowd? Oh, it's for the recording.

Speaker 4: Yeah, I did have a question about the bulk data migration. I guess my question is just in terms of what kind of size of bulk migrations have you seen in terms of the amount of users? Like what's a typical scale that Okta professional services has dealt with, and how long did these engagements usually take?

Jo R.: So we've done migrations right from the beginning and it's scaled over time. Now that we have a lot of focus on customer identity, we're opening up external use cases. We see the user populations getting larger and larger. It's in the millions, yeah.

James: As mentioned yesterday in the general sessions, MLB was about 20 million, and Albertons was about 18 million. So they're huge. You can go from a small company that maybe has a thousand to a medium size, like with what Rocco was dealing with. And then we have the larger-end customers that are in the millions.

Speaker 4: How long did it take? Was that six months, was that a year?

Jo R.: So-

James: Oh, the question was how long does that take.

Jo R.: Yeah. I hate to say this, but it depends really. If the customer is able to do it all on their own, there are no external dependencies, they don't have any other vendors that need to sync up, it's usually very fast, but that's not the case most of the time. So the cycle is much longer.

Speaker 5: My question about Just In Time process you created. So when user that sign in widget, is it something you built or you use the Okta sign in?

Rocco Martin: Sorry, we started with the sign in widget and made a few changes. But for the most part, we kept with that because we wanted to take advantage of the device finger printing and several of the other security features that are built into it. But yeah, it's always a challenge because you take a snapshot of it and now you make some changes, and so when Okta comes and adds the next generation of device fingerprinting or whatever, it's the same thing. Once you customize, now you own the upgrade, and so that's another thing that want to get back down to where we're only theming and not providing custom logic.

James: And on that same note, the auth proxy that they built, you guys built that on your own, right?

Rocco Martin: Yes. With a little bit of advice from Okta.

James: Fair enough. Our professional services team does build these out all the time. We do it so often that what we've done is we've taken a project that does an authentication over to L-DAP, and once you get a valid, successful authentication from L-DAP, it'll actually create you an Okta via JIT. And we've put that project out there on gate hub, so if you go to toolkit.Okta.com, and search for migration, you'll find it there. You're free to download it, test it out, try it, see if it works for your migration or you can actually modify it to work with whatever you're using, because in their case, their source wasn't L-DAP, but their source was another entity so they would take a project like that, adjust for the auth endpoint of the other entity, and it would be good to go.

James: She asked what is the maximum number of profiles you can bring in when bringing in a CSV file. The CSV file, I think it's limited to what, 10,000?

Jo R.: 10,000.

James: 10,000 records right now. So if you bunch them up into 10,000s, you can do it that way, or you can use the user's API and just make it like an iterative loop that will just go through and each line it will create the user.

Jo R.: And we have CSV as a master now as well.

James: We also do have CSV as a master if you wanted to keep your CSV files as the master long-term. But that's another topic.

Speaker 6: So in bulk imports, you mention we can do credentials as well. So those can be done if you're migrating from an older legacy IM system or from AD. So can the passwords be ... the encrypted passwords be migrated using a CSV, like how does it go?

James: So currently right now you can import a hash password object as long as you have the salts. So you have the salt, you have the password, the hash password, you can bring those both into Okta. We currently support SHA1, SHA256, MD5, and bcrypt. So if you have access to all that information, you can actually bring that into Okta. Once the user logs in to Okta for the first time, what'll happen is we'll take the password they entered, we'll hash it with the salt, and do a comparison of the hash you imported, and if they match then we'll go ahead and migrate that user and set that as their password.

Speaker 6: Okay. So is that password saved in Okta?

James: Once they've confirmed it, it's validated that the hashes match, then we save that in Okta and we get rid of the hash. The hash that you imported.

Speaker 6: So it does save in Okta.

James: Initially, yeah. Yeah. But once they've logged in for the first time, it's gone.

Speaker 7: So for the folks leaving here today, what are the two or three guiding principles you would want people to remember to help them have a successful data migration, whether it's through JIT or through a bulk migration using professional services?

Jo R.: So I think often times, migrating the users into Okta, it's not an AD integration or L-DAP, it's often overlooked. You think it's something that's going to happen, right? It's not prioritized. I think you need to be cognizant of this early on in the process, so you need to start thinking which pattern you want to use, what kind of validation testing you want to do, what are your contractual obligations regarding your existing system. So I think you need to start planning much ahead. That's the key thing that I've found because I've seen that this comes in towards the middle of the implementation, okay, we've got to get the users in, and then there's all sorts of complexities that we haven't thought of early on in the cycle. You know?

James: Anything to add?

Rocco Martin: Well we didn't do a bulk migration. But yeah, I really liked that Jo talked about using obfuscated real data. When I've seen previous migrations in another life, if you try to use manufactured data, you'll think everything's wonderful and then you'll find out that 30 percent of your phone numbers are in a bad format.

James: Bad format.

Rocco Martin: Yeah.

James: Cool. I think that's about all the time we have here today. I want to thank you guys for coming and also remind you to use the Oktane19 app to rate the session. Any feedback is welcome because we just want to have great sessions for you, so please feel free to rate the session. And also my colleague Keith Casey will be in here at 3:30 with his session talking with Pitney Bowes, so stick around for that. Thank you.