Moving off the shared drive: folders to metadata, without breaking links

A migration out of a shared drive is not a file copy. Copying the files is the easy part and takes a weekend. The work is converting a decade of folder names, filename conventions and institutional memory into metadata, and doing it without stranding the several thousand Drive links that live in decks, wikis, email threads and partner inboxes.

This guide is the procedure. It assumes you have decided to move; parts 1, 2 and 3 cover whether you should. If you are moving off SharePoint rather than Drive or Dropbox, the SharePoint migration guide is the version of this for a library with content types and a term store.

Step 1: Decide what moves, in writing

The most expensive mistake is deciding to move everything, because "everything" in a shared drive includes working files, personal copies, exports nobody needs and eight years of client deliverables that were never assets.

Write down three lists before anything else.

Moves now. The brand assets, the current campaigns, the product photography still in use, the logo and template set. Typically 10 to 20 percent of the drive by file count and the part that carries almost all the value.

Moves later, or never. The historical archive. Make this an explicit decision with its own justification rather than a default. An archive that nobody has opened in three years can stay where it is, be moved in a second pass, or be moved cold with minimal metadata so it is at least searchable by content.

Stays in the drive. Working files: layered PSDs mid-edit, project directories, InDesign packages, scratch exports, and every document that is not media. See step 9.

The scope list is the thing you will be asked to change three weeks in. Having written it down is what lets you say what the change costs.

Step 2: Inventory before you touch anything

You need four counts before you can plan, and both platforms will give them to you.

• Total files and total bytes, by top-level folder. Google's admin console reports storage by user and by shared drive; Dropbox's admin console reports team folder sizes. For a per-file inventory, the Drive API files.list with fields=files(id,name,mimeType,size,parents,createdTime,modifiedTime,owners) gives you a spreadsheet you can sort.
• File type distribution. The ratio of images to video to documents to design files determines both the storage estimate and how long processing takes on the other side.
• Age distribution. Files not modified in three years are archive candidates and should be scoped as such.
• Duplication. Count files with identical sizes as a first approximation. It will be higher than anyone expects.

Two figures from part 1 constrain the plan and are worth putting in it now: a Google shared drive holds at most 500,000 items including trash and shortcuts, and each user can upload and copy only 750 GB in 24 hours. The second one governs how fast you can pull.

Step 3: Read the folder tree before you break it

This is the step that distinguishes a good migration from a fast one.

A path like Marketing/2024/Q3/Nordics/Product/Kettle/Lifestyle/hero_kettle_oslo_final.jpg is not clutter. It is seven facts that somebody encoded deliberately: department, year, quarter, market, category, product, shot type. Those are exactly the metadata fields you are about to create. Discarding the tree and re-tagging by hand is weeks of work to reproduce information you already have.

The procedure:

1. Export every full path in scope.
2. Sort the distinct path segments by frequency. The top forty segments are your taxonomy, revealed rather than designed.
3. Assign each recurring segment to a field: year to a date field, Nordics to market, Kettle to product, Lifestyle to shot type.
4. Note the segments that mean nothing (New folder, temp, Johns stuff, FINAL FINAL). These are the parts of the tree with no information in them, and they tell you which branches need human review.
5. Write the mapping as a table and have two people who use the library check it.

Filenames are a second source and are parsed the same way. Conventions like hero_, _final, _v3, _CMYK, _1080x1080, market codes and product SKUs are all fields waiting to be extracted with a regular expression.

The taxonomy guide covers designing the resulting structure, and the metadata best practices guide covers which fields to make required.

Step 4: Harvest the metadata that is already in the files

This step has no equivalent in a SharePoint migration and it is the largest single win available here.

As part 2 describes, professional photography arrives with IPTC and XMP fields filled in: caption, keywords, creator, copyright notice, credit line, rights usage terms, and place names. A shared drive never read them, so nobody on your team knows they are there. They have been sitting inside the files the whole time.

Before you migrate, sample two hundred images from different years and different sources and check how many carry a populated Description or Keywords field. On a library with a history of agency and stock deliveries, the answer is usually a large fraction.

Any competent ingestion will read those fields on upload and map them into the library's schema, which means a decade of photographers' captions arrives as searchable text on day one at no labour cost. Confirm the mapping is configured before the bulk load, because rerunning it afterwards is more work than doing it first.

Step 5: Resolve duplicates during the move, not after

A folder-based library accumulates near-identical files, because copying is how people share and exporting is how people resize. Every one of them will migrate faithfully unless you stop them.

Do this while the files are in flight rather than after they land, because a deduplicated library of 40,000 assets is a different thing to review than a faithful copy of 140,000 files.

• Exact duplicates by checksum: keep one, record the other paths as evidence for step 3's mapping, discard the rest.
• Near-duplicates, meaning resized, recompressed or lightly cropped copies of the same image, need content comparison. Near-duplicate detection explains the mechanism and duplicate detection defines the term.
• Derivatives are not duplicates and should not be deleted. A print TIFF and a web JPEG of the same photograph become one asset with two renditions, which is the structural change that stops the two files ever disagreeing again.

Expect the file count to fall by a third or more. That number is the clearest evidence you will have that the migration was worth doing.

Step 6: Be honest about versions

Part 1 covers the rule: Google's documentation says a version of an uploaded file "might be permanently deleted after 30 days or if there are 100 newer versions". Dropbox retains 30, 180 or 365 days depending on plan.

The consequence for a migration is straightforward and worth saying to stakeholders early. The historical versions you are hoping to preserve are, for the most part, already gone. Nothing in the migration causes that; it happened quietly over the preceding years.

What you can carry over is the current file, its creation and modification dates, and its owner. Treat the migration as the point at which real version history starts, and say so, rather than promising a reconstruction you cannot deliver.

Step 7: Move in slices, and pace the pull

Not one bulk transfer. Slices, each one a folder subtree that maps to a coherent set of metadata, so you can check the mapping worked before the next slice.

The first slice should be small, current, and used by the people who will judge the project: the brand asset set, or the current quarter's campaign. Load it, check that the folder-to-field mapping produced sensible values, check that IPTC arrived, then fix the mapping and load the next.

Two rate limits govern how fast you can pull, both from part 1. The 750 GB per user per 24 hours cap applies to copies as well as uploads. The Drive API allows 1 TB of egress per project per 24 hours and returns 403 or 429 on per-minute quota, with exponential backoff as the documented handling.

For a 5 TB library that is a minimum of five days of transfer, and in practice a week or two once processing is included. Plan the calendar around that rather than around a weekend.

Do not forget the desktop clients. Files exist on laptops as well as in the cloud, and a designer with selective sync switched off may hold the only copy of something. Ask, before you decommission.

Step 8: Handle the links that will break

This is the hardest part of moving off a drive and the part most migration guides skip.

A Drive or Dropbox link is an opaque identifier. It appears in slide decks, wiki pages, Notion databases, Confluence, Jira tickets, email threads, Slack messages, scheduled newsletters, partner portals and supplier briefs. There is no redirect facility. When the file moves, the link either 404s or, worse, keeps working and serves a stale copy from a drive nobody maintains any more.

There is no complete solution. There is a sequence that limits the damage:

1. Do not delete the source. Set the old drive to read-only at cutover and keep it for at least a quarter. A read-only stale copy is a much smaller problem than a dead link, and it buys you time.
2. Fix the high-traffic links yourself. The website, the templates, the email footers, the partner-facing documents, the top twenty wiki pages. This is a short list and it covers most of the actual traffic.
3. Publish a mapping. Old path to new asset URL, in a searchable page. When someone hits a broken link, this is what they search.
4. Replace external sharing with something durable. Links you gave to agencies and distributors should become brand portal access rather than new file links, so the next move does not repeat this step.
5. Accept the tail. Some links in some old decks will break. Say so in advance rather than discovering it as a complaint.

The version of this problem you can avoid is the future one. If external parties are given portal access rather than file links, and internal pages link to asset URLs rather than storage paths, the next migration does not have a step 8.

Step 9: Decide what stays, and stop the drive from refilling

The drive does not go away. It stops being the media library.

Stays in the drive: documents, contracts, spreadsheets, presentations, project directories, editable working files mid-edit, and anything a person opens rather than something the company publishes.

Lives in the library: anything that is finished, shared, reused, published, or subject to rights.

The boundary needs one rule that people can apply without asking. The one that survives contact with a real team is: if someone outside your immediate team might need it, it goes in the library.

Then close the path that refills the drive. If the campaign folder still exists and people still have write access to it, files will keep landing there. Set it read-only on the same day the library opens, not a month later, and tell people why in advance.

Step 10: Verify with numbers

Checks that produce a number rather than an impression:

Run the search check with someone who was not on the project. The person who built the taxonomy can always find things.

Timelines

Rough, from the scoped file count, assuming one owner working on it alongside other duties and a migration that includes steps 3 to 5 rather than a flat copy.

The transfer is rarely the constraint. Deciding what things are called is.

Frequently asked questions

How long does it take to migrate from Google Drive to a DAM?

For a scoped library under 5,000 assets, one to two weeks. For 50,000, roughly a month. Above 250,000, a quarter or more. The file transfer is limited by Google's 750 GB per user per 24 hour cap, so a 5 TB library takes at least five days of pulling; everything beyond that is metadata mapping and human review, which is what actually sets the schedule.

Can I keep my folder structure?

Keep it as metadata, not as folders. Every recurring path segment maps to a field: year, market, product, shot type, campaign. That preserves the information and removes the constraint that a file can only be in one place. Most libraries also keep a small folder-like collection structure for browsing, populated from the same fields.

Will I lose my version history?

Most of it is already gone. Google's documentation says versions of uploaded files "might be permanently deleted after 30 days or if there are 100 newer versions", and Dropbox retains 30 to 365 days depending on plan. What migrates is the current file plus its dates and owner. Treat the migration as the start of real version history rather than as a transfer of it.

How do I export files and metadata from Google Drive?

For the inventory, the Drive API files.list with an explicit fields parameter gives you paths, sizes, types, owners and timestamps as structured data. For the bytes, use a DAM connector if one exists, since it will handle pagination, retries and backoff against the API quotas. Google Takeout is designed for personal accounts and is a poor fit for a team library.

What should stay in Google Drive after the migration?

Documents, contracts, spreadsheets, decks, project directories and editable working files. The drive remains the right place for things people edit. The library holds things the company publishes, shares or has rights obligations about. One rule keeps the boundary usable: if someone outside your immediate team might need it, it goes in the library.

What happens to all the Drive links in our decks and wikis?

Some will break, and there is no redirect facility to prevent it. Keep the old drive read-only for at least a quarter, fix the high-traffic links yourself, publish an old-path to new-asset mapping page, and move external parties onto portal access rather than issuing new file links. Plan for a tail of broken links in old documents and say so before cutover.

Previous in the series: shared links, rights and the audit trail. For the broader project around the migration, see the DAM implementation guide.