Microsoft 365 Community OneDrive, 13 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Best practices for data migrations to Microsoft 365

Description

If you are evaluating , kicking off or in the process of moving your organizational data to Microsoft 365 here are some recommendations from the subject matter experts based on their learnings post managing large scale migrations for multiple organizations. Tune in to learn more about the best practices that will help you run an effective, speedy and seamless migration to OneDrive and SharePoint irrespective of the tools you choose to use.

The webinar was delivered live in April 13th, 2021 by Joshua Badach, project manager within the OneDrive and SharePoint customer engineering migration team.

Additional resources:
- Migrate your content into Microsoft 365: https://techcommunity.microsoft.com/t5/microsoft-sharepoint-blog/migrate-your-content-into-microsoft-365/ba-p/1604587
- Best Practices Managed Migration Guide: aka.ms/ManagedMigrationGuide
- Mover Support Documents: aka.ms/MoverGuides
- Migrate to Microsoft 365: aka.ms/MigrationsGeneral
- SharePoint Migration Tool: https://aka.ms/SPMT
- Migration Manager: https://aka.ms/MigrationManager
- Mover: https://aka.ms/Mover

A

All right good morning, good well uh good, good morning, good afternoon and welcome everyone to our event today. uh Today's event is best practices for data migration to microsoft, 365.. We have a lot of really great content for you today and we're thrilled to have all of you here today. Now I'm joined by my colleague, joshua vadish joshua is a project manager within the onedrive and sharepoint customer engineering migration team.

A

He is an expert in all things, sharepoint onedrive and everything that we're going to be talking about today, and I'm super excited for for you to meet him here in a few moments. So really, the goal of today is to talk all about migrating uh large data sets um to to onedrive and sharepoint um and and we're really excited to to dive into this now.

A

This is a teams live event and if you've not joined a team's live event before it is similar to a normal team's meeting but differs in a few ways. The primary thing that you'll want to remember is that the main way that you can interact with us today is through the q, a tab, so that should be in the top right of your screen. So you can just click on that and then in uh in that space you can ask us any questions.

A

We have a few folks who will be responding to those questions via text and joshua will also be responding to those. Verbally importantly, all of today's webinar will be recorded and so you'll be able to watch back today's presentation in full or any sections that you might have missed.

A

So with that, let's go ahead and kick things off, I'm going to bring joshua onto the stage and we'll kick things off so joshua when you're ready the floor is yours.

B

Yeah, thank you, ryan. um I'm excited to be here. This is one of my favorite topics. So again I echo ryan says thank you, everyone for coming. um I have a lot to cover, so I apologize. If I talk fast.

C

B

C

B

I just like talking about it um a little introduction of myself. um I came over from the acquisition of the mover software to microsoft.

B

Almost a year and a half ago, um I worked there for uh almost eight years, seven to eight years, um helping them build the migration tool um and then also leading their their white glove, managed service and sales uh service. So I was there for uh all the largest projects that came through mover that led to the that acquisition, and it's, um as I said something I I'm really excited to talk about. um We touched last week in a similar webinar on how to choose uh the tool within microsoft.

B

That's best for your migration, and this is sort of just a continuation of that the best practices once you've started your migration project and starting your migration project to get your all your data over 10 365 in the smoothest and quickest way possible, keeping your security keeping that metadata. That can be kept, that you need and then, of course, keeping your folder structure and all that user owned data. So your users can uh quickly and safely use the data the m365 in a similar manner to they were the source.

B

um So we start early with some early best practices um that you can start thinking about before you actually do some lifting and shifting of data. um So we talk about scanning for early planning. So you definitely want to understand what you're up against.

B

Likes to have we're going to talk about improving your effective communication during the migration to your end users and and all stakeholders, um and then how to like, I said, set up your and execute migration for maximum speed and as little user impact as possible.

B

So, of course you want to make sure your users are safe and sound in the source, while the migration is happening and using the data as expected, so we're going to start with scan and prepare just so you know what you're up against and we start with scanning your environment, and this is going to give you a heads up on a few things that you really need to start worrying about. um There are tools, microsoft that can help you scan your data mover is certainly one of those um for free.

B

You can easily access your if it's the cloud to your cloud storage source and use their free scanning tool to scan your data. We suggest that you scan all the users their data, so you know exactly how many files each of them have, and you can start anticipating some file and folder issues prior to the migration. That might be a sticking point for that migration.

B

So we start with from those results, um resolve your items with long paths, so you're going to see in a scan, certainly using mover an output report showing you how many files are owned by each user and you can scan every single user, whether you know they have data or not. But it's important to understand these things, but one of the biggest things that it's going to show you are the files that exceed microsoft's long path, limitation of roughly 400 characters.

B

So the path to any particular file in in onedrive and sharepoint can only be so long and, unfortunately, a lot of cloud storage providers allow you to exceed this. um um You know a lot of competitive cloud. Storage providers allowed you to exceed this. These would fail if you were to upload them, try attempt to upload them into m365 due to that limitation.

B

So you want to worry about these beforehand.

B

The scan is going to not only show you what files exceed microsoft's long path limit, but also what users own those the full path to that, and furthermore, movers reporting specifically is able to tell you where you should remediate parent folders to fix the most issues, so we suggest leveraging these reports, so you can clean up these files that exceed microsoft's long path limitation prior to migration, so they don't fail.

B

um Some suggestions for this is communicate this to your users. So often our customers will take two approaches. An administrator will do it on behalf of the users, so they'll have access to the source, uh user's account they'll, take the report that was given uh through the scan process and they'll just go in and manually remediate.

B

Based on the suggestions. The report gives you, but we've seen better results when they put it into the hands of the users themselves, so because this report will clearly show you what users own it and what files are affected by this um csv format, you can easily filter and send out only the files that are relevant to the user. You're communicating with we also say give them a deadline to remediate.

B

This is going to be important because often, if you don't give a deadline when you're doing the velocity migration, you're, actually lifting and shifting the data or copying and pasting the data in the case of microsoft software, um if the users haven't done this, these files are going to fail. So we we see better results when you give that users a deadline, but this also gives you the ability to hold back these particular user transfers. While you do everyone else, that's not affected by a long path um limitation.

B

uh You can do all those other transfers uh hold back those users and then give them a deadline to remediate. So we usually say friday at this time.

B

You can you know you, you must have all of these fixed and if you haven't you're you're, not gonna, we're not gonna be able to be able to upload that data and you'll likely need to manually migrate it um we suggest using movers, scan reporting, in fact, if you're doing a cloud cloud migration, certainly um partners in our partners in our space, such as skysync metalogics, they can do these migrations, uh but mover offers this free scanning tool as well on top of its free migration service uh within microsoft, owned by microsoft.

B

So we certainly say use movers reporting. Why not? It's free and it's easy to use it'll, give you information on these long path, limitations, and this helps you avoid errors that increase migration time. The reality is uh any software if it receives a failure trying to download or upload the data it's going to retry, but of course that retry attempt is going to add time to your migration.

B

So if you can avoid these errors before it hits velocity before you're, actually migrating the data you're going to decrease that time that the software's, retrying and retrying those files, a good real world example of this and uh expedia, was announced uh as a migration customer for for microsoft at ignite 2020., we have a public case study coming soon, uh but expedia was a great real world world example of this, because um we were able to give them the list of the users whose files were affected by this.

B

They did exactly as we suggested gave it put in the hands of the users, gave them a deadline, and by the time of migration they had no files that exceeded uh this long path limitation. We did not see one failure due to this. Of course, any tool you use is going to tell you this failure, if you don't get to it in time, but we say as always avoid errors. If you can- and if you know about it- and you know, there's a way to avoid it, why not do it so?

B

Here's an example of movers reporting showing you these I'm not going to hover on these too long, but we can make this available to anyone who asks, um but you can see here simply it's it's broken out into what user owns it the path and then where we suggest the common parent folder that could be fixed uh to reduce that path length.

B

This is my favorite topic, and I think this is the one that most people ask me about. Is: is data throughput and that's really going to come down to data distribution, how many files each users own and then how much concurrency you can get in the transfer and we're going to talk about that later, a little in a little more detail later, but from the scanning you're going to learn how many files each user user owns.

B

This is probably the most the the most important information you can get from the scan results, because you want to know who owns the most data for that optima optimization of time we're going to talk about in a little more detail, but most cloud storage providers, uh api limit per user.

B

um That means each user is only we're only able to request the the data from um a particular user in your source uh so quickly, um but another user's, transfer and uh limit in that source cloud search provider doesn't affect any of your other users. This means you can stack all your user transfers on top of each other and get great concurrency on that data, but how fast that one transfer goes is really limited to how much data that user owns the owner of that transfer.

B

So, for example, if I owned a million files- and I'm going to give you a number here that you can hold on to is uh roughly one file per second per user can be downloaded. We don't like to talk about downloaded and uploaded. Sorry, we don't like to talk about file size, though package size is important, um but we don't see an impact in migration time when a file is, for example, five gigabytes versus one gigabyte.

B

Really. What matters is that overhead and downloading the up and uploading the individual files, um so the more files any given user has the longer that transfer is going to take at one file per second per user.

B

So we suggest splitting once you've learned that splitting up the ownership of that data to either users not in use on your source or a service account, um because this will give you additional lanes to migrate that data. This will give you additional api calls to to play with because they're per user. So if you have joshua again, who owns one million files, we don't want his transfer to take one million seconds, we'll split that up into we'll take half of that and put it into a service account.

B

um So then we have one million files split between two users that we can run in parallel, each with their own one file per second per user api call limit. um So then both transfers are down to 500 000 seconds versus the 1 million. So it's just keeping that in mind and the scan is going to tell you who owns the most now microsoft's standard is no user, should own uh more than 400 000 items just for the sake of migration speed. This is not a hard limitation. This is not a hard number.

B

This is just a best practice. Any users that own more than that should be that data should be redistributed to keep it below 400 000 items. Thus 400 000 seconds, um we talked about uh package size a little bit. This is going to be really important, is um and file size package size should be around roughly 200 uh 250 megabytes, so uh uh users should own at least that much to get optimum uh transfer speed um so yeah.

B

I I chat about this all of this a little bit here, but uh one point to bring up is highest throughput on evenings and weekends. So you split up your data you're. Getting that the additional lanes of of concurrency each user is getting one file per second, um but the less the healthier your tenant is the less activity on your tenant. The faster the tenant is going to be able to upload same on the desktop the source, how much it's gonna be able to download.

B

Of course, your transfers are gonna work on working hours without affecting the users, but we will get the highest throughput on evenings and weekends. So that's something to keep in mind. uh Mover specifically, has technology to uh analyze your tenants during your migration to make sure you're getting uh the best throughput based on the health of your tenant.

B

So that's something that's automatically happening. If you're using the mover software for your migration.

B

So another best practice remove unnecessary tasks. So when you're managing a migration- and I show examples here- you're- basically creating uh transfer paths and when you're doing cloud to cloud these are typically going to be user to user. As as you can see here, um but you don't want to include users that don't own data, so we talked about scanning. We can see the users that had the most data. What about the users that don't own data? Well, if we included those users, you know they don't own data from the scan.

B

If we included those users, they waste a server space that could be used on somebody that does own data bootstrap time, of course, so we have to load up that transfer. The software has to do it's. It's you know start the transfer has to do with listings on both sides and see. There is no data and then close, the transfer and that's taking time from somebody else's transfer.

B

The server can only hold so many transfers by default. This is 10 using mover, of course, that could be ramped up by asking support, um but uh you don't want to waste time in space with somebody that doesn't own data now, if you're using a cloud to cloud migration tool. Most of those, and certainly all within microsoft, can rewrite your permissions, so the data will still be reshared to those users. They just have nothing to migrate, so there's no reason to create a transfer for them. This is also going to bloat migration reporting.

B

So reporting is going to be extremely important for communicating to your users, your stakeholders, uh the migration. You don't want to confuse anybody by including what we're seeing here is successful transfers, but they owned nothing, because that could confuse users that could confuse your stakeholders and that also makes reporting just harder to go through uh because it has unnecessary tasks in there and then, of course, those unnecessary tasks consume unnecessary api calls.

B

uh We didn't have to do anything against these users, so why use up those api calls against the tenant again that could be used on somebody else.

B

uh We talk about planning and communication. Sorry do we have questions.

C

I just was going to throw one at you joshua this.

B

Was a specific.

C

About investigating some links within the files they wanted to know does the scanning software to the detail of investigating links within files especially excel, for instance,.

B

Yeah, unfortunately, no so what all it's doing is uh counting your files. So all it sees is the name of the files, the size of the files, um but it doesn't know the contents of your files. It's not gonna see your your links, so, unfortunately, no tool we have can do that. As far as I'm aware, this is something we would suggest uh the customer reach out to their source cloud storage provider, for um none of our migration software will recreate any links for you uh if we're doing, sharing links.

B

If that's what we're talking about here. um But uh if, if that's what you need, uh you can request that from your source cloud search provider, if we're talking about internal links like an excel link in or a link within uh excel document. Of course that's carried over um as just contents of the file, uh but mover does no modification to the actual contents of the file or or any migration tool. I know of isn't going to make any modifications or changes to that. So uh hopefully.

C

That would be able to answer.

B

C

I think did- and there was a second question and then I think, we'll move on um that was specific to combining what eric shared last week and what you're sharing today really is just the notion, as does the throughput guideline about number of total gbs applies to migration manager, so I think the question is when mover makes its way into migration manager. Does this all still uh uh retain exactly what you're saying.

B

Yes, absolutely yeah, so one of the best features of this um uh sorry just keep skipping ahead. Oh um the uh um integration is actually they're making scanning better, uh so scanning will be wrapped up into your admin console with migration manager.

B

Obviously- and it's gonna automatically happen, so the way mover is today- um uh and we didn't really talk about it in this call uh in this uh meeting the integration that's happening right now move her into m365 uh post uh acquisition, um but in the future all these features will be here and it's going to automatically happen on your tenant. When you load up your your box, access in the admin console, so it's it's going to be easy.

B

More streamlined, give you the same information, and once the integration is done, uh look at better reporting can be added with the new technology.

B

So we have planning and communication this one. I always say a migration is 90 planning communication. Once it's in the hands of the software, it's really easy to to just track and manage the projects.

B

So we suggest building a project plan and communicating to your stakeholders, um obviously determining who's migrating and then redistribution of your data, I'm not going to touch on too much when we get to that, but because I've already spoken about it and then how to map your users, so we say use a project plan. I mean this isn't too difficult um we're using planner in this example. This is included in m365, of course, um where you can set up all your tasks, sign those tasks to um an owner and then give a deadline.

B

um As always, you know sign an order. Give a deadline is, is really works for planning a project like this, um uh so we say you know, uh remember, to check the plan communicate. The plan have weekly status updates on the plan, but be agile, um uh be be willing to move things.

C

B

You have to um so that's for us a great resource and we can actually help you with the tasks we use internally for migration. So if that's something people are interested in, I can share this project plan with you and you can turn it into your own. um Here's an example of a gantt chart. We use for the same customer so very much just another visual way of seeing uh that plan.

B

uh We we just love being organized over here, so uh we definitely uh when we do our white glove service, we definitely suggest uh using a project plan.

B

Now you need to communicate your plan and this scares a lot of people, but you have to understand if you're, using any of microsoft's tool tools, uh mover migration manager, spmt, it's not gonna, have impact uh on your users in the source. So it's safe to communicate to your users and and say you know we're planning this migration. It's not gonna affect you. um Here's what it's gonna! Look like! um uh Here's our cut over period! That's going to be important.

B

Timeline to address here's, how long we think it's going to take and here's what the delta pass weekend is going to look like and then you're on boarding to m365. So, of course, management needs to understand cost benefits. Users need to understand how this is going to affect them, such as, where? Why are we migrating your data? Where is it being migrated? What are the benefits? How does it impact me, such as sharing links, uh some limitations of files that can't migrate uh depending on what your source is?

B

um So if we're talking about a google source as an example, there's some proprietary files there that don't migrate, um so just understanding those and make sure the users understand those. Then of course the benefits right. There's, there's a ton of benefits to being an m365.

B

As we all know, uh what are those benefits and how can they expect to use it, and then how disruptive is this change going to be? So you want to talk about timeline here, because there will be a period you have to do a cut over and delta pass.

B

Typically, this is just a weekend, and this is the only time we say. Users can't touch the data, because you want to get that new modified data over there before the cut over period. So they need to know about that. Certainly we had when the world goes back to normal and everyone's back in the office we've had clients put up posters in their office. You know something on the fridge saying we're migrating on this day, get ready.

B

um You want to provide a do's and don'ts, um so there are certain things that your users should and shouldn't be doing during a migration mainly move major structural changes, so we'd say: don't move around folders, don't rename folders, because when you have to do that delta, pass it's going to work on differential comparison, um so you'll do that first pass of data eventually that weekend I spoke about where you need to do your cut over um you'll want to do that that incremental delta.

B

um So if they've made major changes, that's going to cause duplication of data, so that's something that really needs to be communicated to your users and I'll show you a template uh in a quick second um final delta passing cutover date. We talked about putting posters up around the office and then preparing your support staff so make sure your support again is aware of the common questions that are going to be coming, and certainly we can help you. Microsoft can help you with that.

B

um uh But again I touched on those a little bit where's my data.

B

You know common concerns of sharing that might happen during a migration, uh the differences between the source and destination, so they know exactly structurally where their data is. If I use an example, um you know, google drive shared with me or box, doesn't have shared with me. So cloud storage providers are different, preparing your support staff for those questions and then your staff. So they don't have to ask those questions.

B

Here's a sample communication template. We give examples uh or sets timeline expectations. It provides the do's and don'ts and of course we can share this after the webinar provides information on unsupported files. This can be customized customized based on your source destination um and then visually communicates the differences between the environments.

B

As you can see here, a slight difference in how um data lands in inbox certainly shared data between box and onedrive, and then, of course, it gives you that guidance for post migration support uh next best practice is going to be extremely important and that's mapping your users accurately. This is for twofold.

B

You need to know that you're putting the data into the right place that one's obvious.

B

So if you're taking the data from any of these users, ry burke, uh you want to make sure you're putting that into to our myburke's uh account, um because, ultimately the software is, it will take the data from whatever path you tell it to and it'll put the data in whatever path you tell it to so you want to make sure that's accurate, but also it's important for re-sharing permissions um mover is able to auto pair as long as the names are exact, um but some software may not be able to do that that we're partners with or you may have users that aren't exact.

B

They don't have a provisioned user or went through a name change. So you need to make sure these match the ones that do not have exact matches for the sake of permissions as well, because the software needs to know who to reshare the data with as it's copying. um So if our weiburg had access to someone else's data, we need to know what their destination upn is to re-show that data.

B

So, as you can see here, um most of the match so we'll do the sharing properly we'll do the mapping of data properly, but you'll need to uh tell us when they don't match and who that matching user is on the destination side. um The mover tool, migration manager they're going to give you opportunities to do that and alert you to uh the users that don't match. This will also show you what users need to be activated still.

B

So, of course, um software is not able to access the user that hasn't been provisioned that doesn't have an active onedrive. uh This is gonna help you determine uh while you're doing this, which users you still need to activate in order to do that proper pairing.

B

um So we do recommend provisioning, your sharepoint online sites, libraries and your onedrive users prior to the migration. So you could do this mapping properly and then don't change your upns during the migration, because you can see how important they are. So so we say, if you're planning, on changing your upns um um wait until after or do it before.

B

However, there's a you know: there's management around what happens if you have to do it during migration that we can walk you through. It just complicates the project a little more and then we say decide on a destination folder name. This is important to us as well, because uh when you're mapping your csv uh deciding where you're taking the data and where you're putting the data, we suggest putting it into a destination folder that you can simply add to the the end of the path on the destination side.

B

This helps keep data pre-existing data separated from migration data, so you can help communicate um and then it also helps like I said those major structural changes um from happening, so you don't mess with the delta pass. You can say to your users in your communication: don't touch the migrated from box. Folder, don't touch the migrated from google folder, whatever, maybe until this date, uh so it doesn't mess with the delta pass.

B

So that's yeah! uh What we're talking about here exactly that is migrating into a migration folder. um The risks of pre-existing data is the merging of folders. That's really the major risk. The delta pass works by uh differential comparison, as I mentioned, um so if you have two folders named the same thing in both source and destination, there are unique folders that hold different content um and you try to migrate it to the same place in the structure.

B

Those are going to merge and then files are going to look at timestamp differences to determine whether or not needs to be migrated. So again we say put it in a migration folder, it keeps things safe and your users, when the migrations are is done, can easily just take it out by using the move function in onedrive for sharepoint, uh organizing for onedrive and spo split.

B

So often our customers like to choose some data to go from uh one place and then into one drive and then often the shared data or the departmental data is going to go into sharepoint online. So a lot of customers like to organize this way own use their own data into onedrive uh department, shared data into sharepoint online team site libraries.

B

You have to plan for this sort of migration because, typically, when you're doing a route user level transfer to onedrive that's going to copy everything within the route, but they may have folders you want in sharepoint online instead, so you have to identify these either through using reporting off of your scans in mover, movers certainly has individual reports that will break down what data is owned by your users, and then we suggest getting that data out of the path of the onedrive transfer, so it's owned by joshua right now, but we don't want that folder migrated.

B

Let's say the sales folder migrated to joshua's onedrive. We need to get that sales folder out of the path of joshua's onedrive transfer. So again, this is about changing ownership to a service account. Then you can map your transfer to that service, account straight to sharepoint online online library that you want copying only that folder or the folders. You know that you want to go to that particular library, so this keeps duplicates at a minimum or mitigates your risk of duplicate data.

B

This will also help you uh organize and track onedrive transfers versus sharepoint online transfers. So you really know that group data is done versus that privately owned data.

B

uh Autodesk was a great example of this. They were scared to do this, so we have a public case study of this. I apologize. I couldn't uh get the link before this presentation, but we'll make sure to share it out to you folks. uh After this um they were a great example of this. um They were easily able to go through each user, determine what data they wanted in sharepoint and not in sharepoint online team sites and not in onedrive, and they did exactly that. They created a service account one for each unique library.

B

They changed the ownership of the box data from a user to these service accounts, and then we simply just mapped those service accounts in box to their sharepoint online library.

B

So this was very straightforward and again we were able to track them separately, so they could tell the users okay, your personal transfer is done, um and then they could tell the the department adds. Okay, the department data is done, uh so this was uh yeah. This was a great example of that it took organization it took uh labor from autodesk in order to determine that and understanding their data, but understanding your data obviously is a extremely important part of the migration as well.

B

Questions on that uh topic, yeah.

A

Either drop down mark I'll, let you go.

C

I just was gonna, throw three questions at you, but ryan. If yours was more tactical, um I don't want to overwrite that.

A

I'll read I'll read the first and then you can go with the the other two. So the first question that uh that I wanted to read out is um one person asks when migrating from a large file store. What's the correct balance between migrating, just all the files over versus having users decide like which files manually uh to move over. Is there a correct approach to find the right balance there like move.

B

A

Or remove just some of the stuff.

B

Yeah, ultimately, you want to think about throughput right so again that kind of comes down to ownership of data um or, if we're talking about a file, share, how the data is distributed between servers um or between that file share. So ultimately, yes, you, if you can do cleanup beforehand. You should do that. um Yeah, this all comes down to throughput and how long your migration is going to take. If you don't care, do it all, do it all at once and do it all.

C

And just let it run we're.

B

Going to have per transfer line again, it really depends on how your source is structured, one file per second per trend.

B

As long as your file server is able to open the floodgates and allow a massive amount of download without limitation, then you're not going to. Then it's not going to matter how many concurrent transfers you can run as long as you know that source isn't going to give back offs, you can give you can load onto mover or any migrating software massive amount of transfers and data, and do it all at once, so it really is going to come down to the limitations of your particular uh file. Share cloud services are easy to predict.

B

You know, and then we've predicted, roughly one file per second per user, a little different on a file share um harder to predict. So we typically say you know, keep each user or home drive or whatever it may be uh down to that similar number. I gave before 400 000 items um so yeah I mean it's personal preference, just understanding those numbers, understanding the limitations that uh microsoft and mover do not control the how fast um or any limitations in downloading the data. um So it certainly is going to come down to that.

B

But we, we very much say clean up your data beforehand because that's just going to make for a cleaner and a quicker migration. So hopefully that was able to answer the question.

C

Yeah, I think it did um and I think that context of knowing your source and destination what they can handle, I think is, is really great advice. uh The other two are are fairly tactical. I think, with what you showed one person was just asking: is there a project plan template that can download so that they could quick start and use it in their own organization?.

B

Yep, we don't formally have anything here at microsoft. um Anything I've shown that I'm aware of anything that I've shown is just what I've used internally. My team have used, but we are willing to share that. It's not obviously not a formal marketing approved document, but of course we can work on that anything. I have here that you've seen I can provide links to um and and what you've seen here, we've used historically even at mover prior to the acquisition uh for our project management. uh um I need to make a correction.

B

We don't use plan, we didn't use planner for the one I showed we use microsoft project um and then we do have common task lists that I can send um that are relevant for most, if not all, migrations.

C

Gotcha, so maybe uh eric davis is, who posted that if you wanted to follow up with us for any direct information we can to reach out and contact. You we'll pass that along to joshua the next one I think gets back to the previous um section, but I think it's important if you didn't address it, I think you might have, but I just want to double check.

C

They were asking for when you move content that may have characters within the file name that aren't allowed, which fortunately is a lot smaller than it was a couple years ago. But if there's anything about the file name or the path, it's too long, how does the tool recreate that.

B

Yeah so obviously yeah there are some files that microsoft just doesn't or some characters that microsoft just doesn't accept. um I can't speak to other tools, but I will speak to how mover does this mover will automatically strip those invalid characters from your file during migration?

B

So it knows that it's not going to be able to upload this file because of an invalid character. It knows microsoft's api is going to reject it and that will show up as a failure in your log.

B

The developers of mover knew that the only remediation was manual removal of those characters, so they just wrote it into the software to do programmatically. So what will happen is any characters. The software knows. Microsoft would reject, are stripped um and replaced with an underscore, and then you see that that name change in your login, so you'll see just a quick line on that file in the log saying name, change too, and it shows the new uh uh version so yeah that will allow the software to accept it.

B

That does technically make modifications to the name of your file and that's why it's logged in the log screen.

C

Great, there have been just a couple other questions, but I think for sake of time, um we'll save probably one or two for the end.

B

C

B

Yeah um and we're near we are near the end, we're at the meat of it now is running your migration, so you've determined how much data youtube your users owned that helped. You determine who's migrating uh that helped. You determine how you had to split up data and that helped you to determine ways to to increase throughput.

B

So at this point you have everything defined. You have everything planned. You know exactly what users are migrating who they map to and for that permission rewriting, you know who they mapped to at both source and destination.

B

Now you can start submitting those files uh to run your migration first and foremost, we suggest running a pilot, uh then we say: notify microsoft of your migration, I'm going to talk on migrating in a big bang approach, using reporting and rerunning your errors and then finally, what the cutover looks like so for running a pilot.

B

We suggest doing this because you want you, you want to know you want your stakeholders to know and your leadership to know what this is going to look like how to impact users, how long it's going to take um uh you know and what the end user experience is going to be.

B

This is going to help you with training as well, when you do m365 training, so we say: choose users that are willing to cooperate, because you might need to wipe out that that pilot um you might need to get feedback from users on what the data looked like when it landed, where the permission is still, there um only include users who own data, because you'll just confuse users who don't don't include any users that own a lot of data, because, as we talked about one file per second per user, will take uh too much time for for a test include users that are sharing data to each other.

B

So you can see those collaborations being reset during the migration. um Now one confusion that comes up a lot is your pilot users do not need to cut over to m365 early and separate from everyone else.

B

This is a common misconception once the data is there, we can sit on it and then, when the main migration happens, it's just going to do a differential comparison that delta pass for these users or you can wipe out the data and just redo those users that's time, but it's free using mover, so there's really no risk to doing that and then run as many pilots as you need for management buy-in.

B

You know we have um if you're doing this yourself on mover as an example, uh you can do as many of these as you want. You know the tools designed to to allow you to pick and choose what transfers you're running. You can load them all up.

B

um You can tag your pilot users and you can filter by your pilot users and really track them that way, um but run as many pilots as you need fast track who uses the mover software so the fast track service that will run your migration for you under certain conditions.

B

They will certainly allow you to do as many pallets as you need as well. We also recommend notifying microsoft if your migration is over a hundred terabytes and there is a path for this. An official path for this in you yourself, the customer or your accounts team, if you're working with an accounts team to submit a request, um a form that I do believe we share later in this um alerting microsoft.

B

So they can prepare your tenant for what's about to happen, so this will just be ensuring that the health of the tenant is there, there's nothing preventing uh mover from uploading as much data as possible. uh So it's just a short form that says you know: when are you migrating how much data you're migrating? When do you expect to be done?

B

So we do recommend doing this. If you have over 100 terabytes, this will help keep the health of your tenant and the destination. You know and it's optimal um space to upload that data.

B

This is the scariest one for a lot of people running your migration is a big bang and often I have to convince customers that this is okay, but the reason why we suggest this the biggest reason is that it will provide the highest concurrency for the quickest migration scenario.

B

So the way most software is created that I'm aware of, but certainly mover and migration manager is, you can load up all your transfers at once. All of them. Let's say you have a 10, 000 user transfer. You can load up all 10 000 uh transfers. Huge run uh mover in particular will limit how many of those can run at any given time just to avoid hammering source of destination servers.

B

um But as one finishes, the next will take its place and they'll just keep doing that while you're sleeping right or while you're, working or and you can go check on it for status updates. um Often we get customers that come to us and say hey this pilot, or this migration isn't going as fast as we expected and we found in that they just weren't submitting enough jobs. So we would see. Oh you weren't submitting data the last couple days.

B

um You need to constantly be submitting data, so we recommend just throwing them all in there. The reason why this scares a lot of customers is because they believe support will be hammered the day of cutover. If you're doing the your entire organization, um we found that to be from customer feedback.

B

Autodesk certainly gave this feedback um uh in their case study they overstaffed on that first week and they actually laughed about it to us after they were expecting more support questions, and we found that uh if your colleague next to you, they might be in a different team, uh whatever it may be, the water cooler chat. You know everyone hanging out with the water cooler, um that's where we can ask questions, because uh you know we're more comfortable asking our friends and colleagues. um You know where did my.

C

B

End up or or things like that, so um big bang is going to give you a quick migration. um There won't be breaks in between it. um You know there will be stopping to to plan what your next phase is plan the scheduling of your next group. um It also avoids sharing concerns. So if you did your migration in groups departments as the most common example- and you certainly can do this way, but what if your data is shared between those groups, um you certainly don't want someone who has access to data.

B

That's already had its delta cut over a week prior in a different group, editing that data, because there's not going to be another delta picking up that data.

B

So it's important understanding that if you have groups sharing with each other but you're migrating in separate groups, um there is going to be concern with those collaborations that you need to worry about, um and then yeah, as I said, I think the biggest one is concurrency is the key to throughput mover will be constantly monitoring the health um to make sure you can have the max 10 current transfers, or you can request higher um if you're going through fast track. You can request that from fast track.

B

Of course, if you're self-serving on the mover tool for free, you can request that from uber support um so that you're running up to 100 transfers at once, which will uh will give you a speedy migration um use migration reporting. So we very much say: use reporting that you're getting from your software, we're proud of movers as well and, of course, we'll be wrapped up into migration management.

B

When that's done, because that's going to give you a full report of all the failed files when your migration is done, so you can see exactly what why the file failed, what the file was, who owned it all in one csv. We have other reports that will show you the status of the migration, so basically a report out of the ui. You would see if you're self-serving, that's color coded that can show you certain information that you can print out and share to your stakeholders and leadership as well.

B

So we certainly say use that uh the reporting, the the consolidated reports, but, of course you can get individual user uh reports as well that go right down into um with the users on and um um to see that granularity, uh but keeping in mind with movers. Specifically I apologize. I should have put this here. Those logs are only available for 90 days for security purposes.

B

uh Best practice rerun your errors, so at this point you've run your migration. You've done a big bang approach, you're using reporting to see what transfers have failed files. This is clearly shown in status and it's clearly shown with that. Color coding I mentioned so a transfer that has any failures will will end up error or yellow. We recommend re-running this. um You know consistently until you get a consistent number of failed files, because often we'll see back off failures um that can be remediated. Just by re-running your transfer anytime, you rerun a transfer.

B

It's going to do a differential incremental. It's going to do that differential comparison and only migrate. What hasn't already been migrated or what's been updated based on timestamp, so you see a yellow transfer rerun that because there's a good chance that failure in the log is a back off that can be picked up just by doing a simple rerun. If it doesn't clear up that same file, you know, there's a permanent problem: it's not a transient error! So then you can really start digging into that and asking support what's going on with this file.

B

So as again transient errors are something you want to avoid reporting to your stakeholders. You don't want to report something that you could just fix by doing a rerun and.

C

Then, as I said, rerunning.

B

To get consistent number of failed files mover is going to show you how many field files you have in a transfer during its run, so you can clearly see that decrease or stay the same. That's sort of the stuff we look for is that consistency um and then again, transiting error is bloat.

B

uh You want to avoid migrate migration reporting bloat, because you need to share that and you need to download that for download that from the microsoft servers, so the larger that is the harder all of that's going to be um uh another optimization, that's built into the software is mover, will automatically rerun your transfers up to two times if it completes with an error, so we sort of thought about this and handle it for you in that we know.

B

There's there may be transient errors, mover software will just automatically kick it off again, so don't be afraid about this and then, like I said it's going to do that differential comparison. It will do this up to two times, so you can it'll help. You see that consistency or if it's a transient error now the final delta in the cut over this is the end of your migration. You've done your planning, you've done your communication. You've you've defined your migration um with a csv you've uploaded it to the software and that's actually doing the migration.

B

Then you've done your big bang approach and you've done your first pass of all of the data. This first pass. You know, if you're doing a big bang approach, it's a copy and paste if you're using mover, so it does not affect the users using box or google or dropbox or ignite or any of the cloud storage providers, you're leaving or file share, but you will eventually need to do a delta to pick up new modified files if the users are using the data, while you do the migration.

B

um So this is the time where you're going to communicate to your users. You cannot use the data after this point um usually friday evening, uh regardless of time zone based on their time zone uh and then you're going to want to run or fast track will run if you're using the fast track service. A delta pass to pick up those new and modified files, and this is very quick.

B

It's just a listing of the data on the users, it's looking at the timestamps between source and destination uh and the name since determining what needs to be copied over. uh We recommend running a full delta prior to that weekend to gauge the timing of that delta. So, ideally, you're scheduling your final delta a little bit after the main migration is done with a little breathing.

B

um So then you can do a delta and determine if it's going to take just overnight, depending on the size of your migration, two nights or even three nights to anticipate in case. You need that sunday or monday morning to complete it do that full delta figure out how long it takes now. You can communicate to your users how long they can't have access to their data again on a weekend.

B

um You, of course, want to prevent the users from editing or adding delta, during or after or data, during or after this delta, because this is the final delta. uh Any changes will not be copied over unless you do another delta um communicate this day and its boundaries with notice that one's an obvious one and then plan to use the entire weekend.

B

Even if it's done saturday morning, which is common saturday night, which is common, um give yourself the entire weekend just to validate that everything went well and that's actually, one of the benefits of running a delta prior to the weekend is to validate that it's going to go well and that you've handled all the errors you need to, and you know what to expect the expectation then is first day monday morning, your users will be using the data as expected and as planned.

B

So that's the end of it. I apologize if it was a lot. I give you some resources here, but we'll also share it, but feel free to feel free to use this email address, um uh give it to your accounts teams. If you have questions on migrations, if you need some migration, consulting and you're uncomfortable reaching out to me directly give it to your accounts team and they can reach out to me and we can get you some migration expertise and advice as needed. That's what I'm here for.

C

uh Joshua, there are two final questions that I think will be nice to wrap up on and certainly with all the resources and your availability through email is, is a wonderful offer and then I've got one announcement just based on the most common question that wasn't content oriented, but first the content.

C

Is there any way to check the last accessed file on a file like compared to modified or created similar to what you were saying around the context of don't bring everything? If you don't have to maybe they're asking? Can I review through this criteria of what was last modified or created.

B

Yeah, unfortunately, no not built into anything we own, um so yeah, there's no filtering option. There's no filter by time stamp. There's no filter by file type. These are features we're thinking of adding in the future once that integration is done.

C

The other one is specific to box, and it's got a nuance around working with external users and I'll kind of front load with, certainly always understand the destination. If you want to share externally once files are in microsoft. 365 of course support that. But the nuance is when they're migrating off of box and they have files and folders that are shared with external users.

C

Is there a way to map that during the migration and with the context of setting up the destination with the right permissions? How would you think about things that have been shared already with external users.

B

Yeah this is, I I hate to say, but one of the toughest topics when talking about a migration is we don't have any internal way to really help with that. um So none of the tools microsoft owns will re-share externally.

B

um This is partly and of course they would need an m365 account to share too, uh but it's also a security concern. So we believe that, um and the way most you know, migration services do their permissions is simply by reading access on the source and pairing that to a destination user, then writing that same access on the destination.

B

Now, if mover, were to do this from a securities perspective, it would just send out notification to um those external users that data has been shared to them right and you may not want um you may not want that to happen. It might be old data. People do gain access to it, so I I hate to be that guy, but the the only advice we really have on external sharing is understand it in the source.

B

Then manually set it in the destination either at the folder level, pre-migration on a parent folder or your sharepoint site, or on the data on the destination.

B

If we're talking about box box can get you this report of all folders that are shared externally and who those externals are, but unfortunately it's manual work, so whether it's you know something you have your users re-share their external data uh post migration as needed. This is a great time for cleanup of your data and from a security perspective um or writing a script.

B

We've had some customers write a script on the destination side uh once they understood the folders that were shared to those externals that would go through and reshare the data to the externals, so there's nothing programmatic and internal and internal. I can think of that, can do that for you, um but box certainly can help with that, um but the software won't transfer those external permissions.

C

Yeah, I think it's important what you said. You know it goes to the the planning and the execution once you know your source and destination and that we don't change permissions, but you can certainly set the destination to adhere to how you want to share your files, then, hopefully it's just a to b and and then activate um so the last thing and joshua I'd love to get your sort of final digits on the summary of. What's the what's the top, something that somebody should think about before they think about moving into microsoft, 365..

C

But the the one uh broader note uh that question was asked a number of times: is the session being recorded and was the previous session recorded and absolutely they were recorded and we're going to make it really easy to find on the original blog post that ankita published we'll have both links out there or if you go to the original links per each session, we'll make sure that the video shows up there as well, so that you can access that on demand. But final thought from you joshua and then we'll. Let ryan take us out.

B

Yeah, I would say, on the the most important thing, is understanding the differences between the source and destination, how you use the source and how you're planning to use them 365 and if those match um so obviously you're going to want to worry about integrations with third-party apps. Will those third-party apps work in m365?

B

Will the users have access to the same data that they had access to before?

B

Will they be able to use the data in the same way they did before and are we getting features that uh we didn't have before that we want?

B

So, I would say, understanding those major differences and setting your users up, for that is going to be one of the most important things: the differences between environment and how the data is exposed, how the data is shared and how users get to that data should really be understanded understood because from there you know once you've done your planning and you're actually executing the migration it that's the easy part. The hard part is the the you know: the user management, all that change management.

B

You have to do that, doesn't even involve the software, um so I would say: yeah. That's the most important part understanding how your users that use the data, the limitations of source and destination, the the differences in the environments. Then, of course, um that change management that uh and communication with your users on all of that stuff. From there it's just going to be loading jobs and doing status updates.

A

Awesome joshua. Thank you so much for all this great information and thank thank all of you uh for attending. Today. We appreciate your questions. Your engagement, it's been really great um hearing from all of you about your questions and concerns, and and uh and things that you'd like to learn more about as far as it uh goes to onedrive and sharepoint and data migration. So with that, thank you all for joining. We look forward to seeing you at a future webinar and wherever you are in the world, take care and have an excellent day thanks.

B

B