Google Drive Migration

The copying is usually the predictable part, and Google's limit of 750 GB per user per day is what sets the floor — a large file server moved through a small number of accounts takes as long as that arithmetic says. What varies enormously is the work either side: deciding the destination structure, redesigning access, and getting departments to say what is still live. In our experience the transfer is a weekend and the decisions are a few weeks, which is the opposite of how most people budget it.

No, and it is important to plan for that rather than be surprised by it. A file server expresses access as layers of folder permissions built up over years; Google expresses it as membership of a shared drive plus one of five roles. There is no faithful conversion between those models, because they describe different things. Somebody has to decide what access ought to be — which is genuinely useful, since it is the only occasion on which anyone will ever review it, and most file servers contain permissions nobody can explain any more.

Usually a split, decided deliberately. Converting gives you proper simultaneous editing, comment threads and version history, which is most of the reason for moving. It also alters complex formatting and can break elaborate spreadsheets with macros or unusual functions. The workable rule is to convert what people genuinely collaborate on and leave the rest as Office files, which open and edit in Drive perfectly well. What does not work is letting the decision happen by default and finding out which spreadsheets mattered afterwards.

Shared Drives, for anything the business would miss. A file in My Drive belongs to the individual whose account holds it and leaves when they do; a file in a shared drive belongs to the organisation. Since the usual reason for migrating in the first place is that the business cannot reliably find or keep its own documents, landing everything in personal accounts moves the problem rather than fixing it. The drive structure and the roles are worth settling before a single file is transferred.

For a small volume, yes, and we will say so rather than quoting for a project. At any real scale it is slow, it runs into the daily limit without telling you anything useful, and it gives you no record of what succeeded and what quietly did not. The thing that matters at scale is not the copying mechanism but the reconciliation afterwards — being able to demonstrate that what was on the server is now in Drive, which a drag and drop cannot.

It depends on the source, the volume and what has to be preserved, and we establish that per project rather than committing to one answer in advance. Google offers migration tooling, and there are capable third-party products; which is appropriate for a 200 GB Dropbox is not what suits a 4 TB file server with fifteen years of permissions. We would rather confirm the current state of the tooling at the time of your project than repeat something from a page written months earlier, because this is an area where what is available changes.

Not if the reconciliation is done properly, which is the part worth paying for. The old system stays in place, read-only, until the new one has been checked — not until the transfer finishes, which is a different and much weaker test. What genuinely does not survive a migration is things that have no equivalent in the destination: elaborate permission structures, some retention arrangements, and formatting in converted files. Those are identified in advance rather than discovered.