Key Takeaways — brief reading, less than 30 seconds
- Drive is good file storage and a poor asset manager. Five failure modes recur: folder-shaped search, “anyone with the link” sharing, broken links when folders move, buried version history, and no preview for creative file types. They tend to surface together, not one at a time.
- Don’t move everything. The import-worthy share of a typical Drive is a minority of the library; the rest is duplicates, drafts, and orphans. Migrate the active layer, leave the rest as cold storage on a downgraded Drive tier, and revisit in six months with evidence rather than guesses.
- Migration is the moment cleanup pays the most. Three passes worth doing first: de-duplicate, flatten the hierarchy, plan the metadata schema. A day of prep saves months of retagging later.
- Three migration methods match three library sizes: manual drag-and-drop for small libraries, bulk via the Drive connector for the middle tier, API with custom folder-to-tag mapping for large ones. Vendor “migrate in an afternoon” demos use the sample library, not yours.
- Run Drive and the DAM in parallel for two to four weeks. New files into the DAM, in-flight projects finish where they started, the brand kit moves first. Same-day cutovers are what kills migrations.
- Adoption is harder than the technical work. Lock writes on migrated Drive folders so the team isn’t deciding where to save every file. Engineer two or three two-second-search wins in the first week. The loudest resister is usually the heaviest user, and the easiest one to flip.
- After migration, downgrade the Drive tier, lock project folders read-only, and set a six-month review for what you didn’t migrate. Workspace stays for Docs, Sheets, and Gmail; the DAM holds the creative output.
Editor's note: We built a Google Drive import tool for YetOnePro because most of our early customers migrated from Drive. Two prerequisites for this article: What Is Digital Asset Management? answers “do I need one”, and How to Choose a DAM covers picking the destination. This is the tactical migration manual.
Most teams arrive at this article the same way. A client says the link you sent in August no longer opens for them. A freelancer leaves and takes access to the original Q3 photography with her. Someone recreates a hero shot from scratch because nobody could find it before the deadline, even though the file was there the whole time, three folders deep, named in a way only the person who saved it remembered.
No amount of folder reorganisation will fix this. Drive does a fine job of storing files. It does a poor job of the work the team has come to need from it: finding an asset by what it shows, knowing which version went to the client, transferring ownership cleanly when somebody leaves.
When Google Drive Stops Working#
The failures have specific names. Calling them “cloud storage limits” is one reason teams stay on Drive past the point it works; the failures don’t feel like a category problem until you see them itemised.
The five symptoms that tend to arrive together:
- Search returns folder-shaped answers. Drive’s search ranks by recency and filename. There is no way to ask “the orange-sky photo from the Q3 campaign” without remembering what folder it’s in. While the library is small enough that one person remembers everyone’s folders, this works fine. After that, every search starts looking like a guessing game.
- Sharing is broad rather than workflow-aware. Drive offers viewer/commenter/editor on a file or folder, to named accounts or to anyone with the link. There is no native “these three folders for this client, expiring Friday, no download” without rebuilding the access list every time.
- Access drifts when files move between owners or into Shared Drives. Drive URLs themselves are stable, but reassigning ownership during a clean-up, or relocating files into a Shared Drive with a different access policy, can quietly remove access for people who already had a link. Auditing what an external collaborator can still open is hard.
- Version history is buried. Drive keeps versions; nobody uses them. The UI hides them three clicks deep, doesn’t mark which version is approved, and lets anyone overwrite the canonical without flagging it.
- Creative-file previews are flat. Drive renders Docs, Sheets, and PDFs in-browser. PSD, AI, INDD, RAW, and 4K video all download to the desktop before anyone can see them.
These symptoms show up together, not one at a time. They surface around the point where the team has grown past the size where one person can hold the folder structure in their head, and the asset library (often pulled forward by video, by multiple concurrent campaigns) is large enough that the storage bill is climbing of its own accord. Both pressures push toward the same conversation.
If you’re still working out whether the answer is a DAM or just better discipline, the foundational What Is Digital Asset Management? piece walks through that decision. This article assumes you’ve already made it.
What to Migrate and What to Leave Behind#
The instinct on every Drive-to-DAM migration is to move everything. Don’t. When teams audit honestly, the import-worthy share is usually a minority of the library. The rest is duplicates, drafts, and orphans nobody has opened in two years.
Migration is not the moment to drag that mess into a clean system.
The audit takes an afternoon. Sort Drive by last-modified date. Anything not touched in eighteen months is archive-or-delete unless it’s legally retained or historically valuable. Migrate the active layer first, leave the rest as cold storage on a downgraded Drive tier, and revisit in six months: if nobody’s asked for any of it by then, the answer is deep-archive or delete.
Worth migrating:
- The current and previous quarter’s campaigns and active project folders
- The brand kit (logos, fonts, templates, photography, video assets — everything brand-restricted)
- Anything tied to a current contract or licence (rights-managed stock, talent releases, music sync)
- Reference work the team actually consults: mood boards, past launches, reusable photography
- Files with non-trivial metadata you’ve already added (tags, descriptions, captions you’d hate to retype)
Some categories are better off staying on Drive. Personal folders, individual scratch directories, anything ending in _v2_v3_FINAL belongs to its uploader, not the workspace. Google Docs, Sheets, Slides, and Forms can’t migrate as-is because they’re live collaborative objects rather than static files; export to PDF or XLSX if a specific document needs to land in the DAM as a delivered artefact, otherwise leave them in Workspace. Files older than two years that nobody’s requested in the last six months and have no contractual reason to keep are archive candidates.
The audit deserves its own framework; the creative asset audit piece walks through the four-way decision matrix.
Preparing Your Files Before the Move#
Migration is the moment cleanup pays the most. What arrives at the import boundary is what your team will live with. A day of prep saves months of after-the-fact retagging.
The work that pays back the most is unglamorous and front-loaded:
De-duplicate. Brand assets in particular tend to accumulate copies across personal folders as people download and re-upload them on the way to a deck. Drive doesn’t ship a built-in duplicate finder, so the realistic options are sorting by name and removing obvious copies by hand for a small library, or running a vetted third-party Drive duplicate tool for a large one. Keep the one in the canonical brand folder; archive the rest.
Flatten. Folder hierarchies six levels deep are a sign that someone tried to hold information in the path that should have been in metadata. The DAM uses tags and custom fields for that work; the folder structure should mostly disappear after migration. Flatten the hierarchy down to two or three levels at most before you start.
Plan the taxonomy. Decide what tags, custom fields, and metadata schema the DAM will use before you import. Five or six fields are usually enough: campaign, channel, status, owner, brand-restricted, expiry. Doing this upstream saves weeks of after-the-fact retagging. The full design rationale lives in DAM Metadata Taxonomy; the short version is that designing the schema before the import is what keeps the next twelve months sane.
Migration Methods: Manual, Bulk, and API#
How you actually move the files depends on how many of them there are and how much metadata you want to preserve. Three patterns cover almost every case.
Manual drag-and-drop. Works for small libraries — the kind one person can shepherd in an afternoon or two. Surprisingly effective for a first pass because you make decisions on the way through: rename, retag, drop the orphans. The metadata you retain is whatever the DAM extracts from EXIF/IPTC on upload, plus the folder name (which most DAMs auto-import as a tag).
Bulk via Drive integration. The standard path for the next tier up. Most DAMs ship a connector that mounts your Drive, lets you select folders, and imports with the structure preserved. The connector typically carries file names, timestamps, folder hierarchy (as tags or collections), and embedded metadata. Drive-specific fields like the description column or appProperties are usually not mapped by default, so check what your vendor’s connector reads before relying on them coming across.
API migration with custom mapping. The right answer for large libraries, especially if you have folder-name patterns that should map to specific tags or custom fields. It costs developer time — expect to budget for the mapping work, a dry-run, the live run, and a cleanup pass — but produces the cleanest landing on the other side. A typical script reads Drive’s API, parses folder paths, and applies tag rules (e.g. /Campaigns/Q3-2025-Holiday/Final/ → Campaign:Q3-2025-Holiday, Status:Final, Year:2025) before pushing through the DAM’s import endpoint.
As a rough planning line: a few thousand files via the bulk path is a long weekend. Tens of thousands via the API path is multiple weeks of calendar time, once dev, dry-run, live run, and cleanup are accounted for. “Migration in an afternoon” in a vendor demo is the sample library, not yours.
How Folder Structure and Metadata Cross Over#
The biggest fear on every migration is losing the organisation that already works. Some of it transfers; some doesn’t. The part that doesn’t was usually a workaround for Drive’s limitations rather than something worth carrying forward — the folder named __CURRENT__ at the top of the tree, the parallel _archive hierarchy nobody has read in two years, the dated subfolders that exist because there was nowhere else to record approval state.
Worth knowing before the importer runs:
- File names, timestamps, and folder hierarchy all carry over, though DAMs do this differently. Most collapse source folders into tags or collections. YetOnePro imports through Google’s Drive Picker: you select the files or folders you want to bring across, and they keep their structure on the way in — so the team’s mental map of the selected slice still works on day one. The same import reads embedded EXIF/IPTC and runs AI tagging.
- Embedded EXIF and IPTC metadata follows the file. Camera settings, GPS, copyright fields, captions added in Lightroom or Photoshop — all of it lands intact.
- The owner field usually maps to whoever last modified the file in Drive. This is correct for some files and wrong for others; see the FAQ on Shared Drives below.
- Drive descriptions and custom properties are the usual casualty. Drive’s API does expose
description,properties, andappPropertiesas key-value metadata, but most off-the-shelf DAM importers don’t map them by default — they bring across what’s embedded in the file (EXIF/IPTC) and skip the Drive-shaped fields. If a team has spent a year writing descriptions on Drive files, ask the DAM vendor whether their connector reads those fields, or plan to map them via a custom import script. - Sharing permissions, version history, comments inside Docs, and Drive-specific flags (stars, priority) don’t come along. Rebuild sharing in the DAM (which is the right model anyway) and accept that version-1 in the DAM is whatever you import.
Folder-to-tag mapping is the most useful structural conversion, and the part DAMs handle differently. Standard bulk connectors typically apply folder names as flat tags, so a file from /Campaigns/Q3-2025-Holiday/Final/Banner-Set/ lands tagged Campaigns, Q3-2025-Holiday, Final, Banner-Set. Turning those into structured key:value tags like Campaign:Q3-2025-Holiday, Status:Final, AssetType:Banner is generally custom-import-script work (the API path described above), or a feature of a smaller number of DAMs that let you define path-pattern rules during ingest. Either way, the payoff is the same: after import, the holiday banners are findable by filtering tags from anywhere in the library, without having to remember which folder they live in.
On versioning specifically, if your team leans on Drive’s version history today, the new conventions in the DAM are where most migrations stumble. The version control for designers piece covers what good versioning conventions look like in a system that surfaces them properly.
On the metadata gap, AI auto-tagging fills part of what your import doesn’t carry. Our take on AI image tagging covers where it works (broad subject categorisation: “car”, “beach”, “person smiling”) and where it doesn’t (campaign-specific or context-dependent retrieval). The taxonomy you designed during prep is what handles the rest.
The Parallel Run: Using Both During Transition#
The migration most likely to wobble is the day-one cutover — the Monday morning where Drive goes read-only and the DAM becomes the team’s only system in a single step. Don’t do that. Run Drive and the DAM in parallel for two to four weeks instead, with clear rules about which files live where, and let the team learn the new system on real work rather than a training session.
A trial proves the tool works. A migration is what the team works in for years afterwards.
The rules that keep both systems coherent during the overlap:
- New files only into the DAM. From the day the DAM goes live, no new project assets land in Drive. Drive becomes read-only for the projects in flight; the DAM is where new work happens.
- Existing in-flight projects finish where they started. A campaign already mid-flight on Drive finishes there. The DAM picks up the next campaign. Splitting an in-progress project across both systems is the worst of both worlds.
- Reference and brand assets land in the DAM first. The brand kit, current campaign assets, and the references the team actually pulls from move on day one. This is the part that builds the team’s trust quickly, because it’s where they look first.
- One person owns the “is this in Drive or the DAM?” question for the first month. Usually the person running the migration. They answer the Slack pings; the team doesn’t have to remember the rule on the way to a deadline.
The signal that the parallel run is over: nobody asks “is this in Drive or the DAM?” for a week. At that point, switch Drive to read-only company-wide and start the six-month review clock for the long-tail archive.
Getting Your Team to Actually Switch#
The hardest part of a migration has very little to do with files. People default to what they know. A team that’s been on Drive for five years has habits in their fingertips for where to look, who to ask, how to share. The DAM doesn’t beat those habits until the team has used it on real work for a couple of weeks. Adoption is what happens between the system going live and the team actually going there first.
A few practical levers, in rough order of impact:
Make the DAM the only place current files live. If the team has a choice between a clean DAM and a familiar Drive, they’ll pick Drive. Lock writes on the migrated Drive folders once the parallel run ends. This takes a save-location decision off their plate, and a familiar option that stays one click away rarely loses out to a new one.
Engineer some early wins. Spend the first week finding one or two two-second-search moments for each person on the team. Pick the asset somebody’s asked for in Slack three times this month and show the search result. After two or three of those, people stop calling it the new system.
Tell the team where Drive still wins. Drive remains the right home for live document collaboration, for personal scratch space, and for the Slack-attached file that needs a home for two days. Saying this from day one prevents the “but I still need Drive” pushback in week two; the DAM was never going to replace Workspace and saying otherwise sets up an argument you don’t need.
The loudest resister is usually the heaviest user. The team member who pushes back hardest is often the one with the deepest Drive workflow built up over years, which also means they have the most to gain from a tool that handles it properly. Spend an hour with them in the first week and port over their three most-used reference folders. In our experience, this is usually where resistance flips fastest.
After Migration: What to Do with Google Drive#
Don’t delete Drive. Google Workspace stays for Docs, Sheets, Slides, and Gmail. Drive itself stays as cold storage for the long-tail files you didn’t migrate, plus the scratch space the DAM was never meant to be.
Once the parallel run ends, the week that follows has a small to-do list:
Downgrade the Drive tier. If you were paying for the higher Workspace tier mainly for storage, drop a level. The DAM holds the asset library now; Drive only needs to hold what you didn’t migrate. The saving on the Workspace bill is often enough to cover a meaningful share of the DAM subscription on its own.
Make the project folders read-only. Lock the folders the team migrated from. Read access stays so anyone can pull a historical reference; write access goes so new files can’t accidentally land back on Drive. This is the structural backstop for the adoption rules above.
Set the six-month review. Put a calendar reminder six months out. The question to ask at that point: did anyone access the folders you didn’t migrate? If no, deep-archive or delete the lot. If yes for a small number, those are the folders worth migrating in the second pass; you now have evidence rather than a guess about what the team actually reaches for.
The migration itself is straightforward once it’s scoped honestly. The change the team feels afterwards is quieter than the marketing material suggests. Search returns the right asset on the first try. A shared link survives a folder rename. Assets belong to the workspace rather than to whichever account happened to upload them. After a few weeks, the file system fades into the background, which was the goal all along.
Frequently Asked Questions #
What happens to the Google Drive links my clients are already using?
Do Google Docs, Sheets, and Slides migrate to a DAM?
Do files in Shared Drives migrate the same way as files in My Drive?
