Where should we put large Photoshop files during a cloud migration?

I’d separate collaboration documents from active design assets instead of forcing everything into one destination. Teams and SharePoint can work well for many office files, but large, frequently edited binary files have different needs: reliable access, predictable performance, version retention, and workflows that avoid multiple people syncing and editing the same file.

Before choosing a platform, inventory the files. Look at file sizes, access and modification patterns, duplicates, and which projects are active versus archival. Then test representative files with the actual design team and applications. Include upload and download times, concurrent access, recovery, and what happens when a sync is interrupted. A small proof of concept is much safer than committing the whole library based on a storage estimate.

Possible designs include keeping active assets on managed file storage, using a cloud file service with a local cache, or evaluating a specialist creative workflow service. Each has costs and operational tradeoffs. Ask vendors for a migration plan that covers the volume, metadata, permissions, and verification, not just a claim that the files can be uploaded.

Don’t assume the 3 TB number tells the whole story. Find out how many files are multi-gigabyte projects, how often they change, and whether there are many duplicate or obsolete versions. Also check the storage and version-retention rules for each proposed service. Repeatedly saving large files can make storage use grow, and the exact behavior depends on the platform and configuration.

Adobe Creative Cloud may be an option, but having enough nominal storage is not the same as having a workable bulk migration or team workflow. Get specific answers about migration tooling, permissions, recovery, file locking or simultaneous edits, and how users will access assets. Don’t treat it as the answer until those details are tested.

If leadership wants a cloud-first plan, ask them to define what that means for this workload. A cloud file service with a local cache, object storage for less frequently accessed material, or a separate managed storage system are different approaches, and none is automatically a drop-in replacement for the existing share.

Put the tradeoffs in writing: capacity and recurring costs, access speed, backup and restore, support responsibilities, and user impact. A pilot with real design work can turn the discussion from “cloud versus on-prem” into a decision about requirements and measurable results.

Short version: I wouldn’t move active, large design files into a sync workflow without testing it first. Syncing folders of large binary files can create frustrating delays and conflict or recovery problems, especially if people expect them to behave just like a fast shared drive.

Keep a proper storage option on the table, whether that means retained local storage or a cloud service designed for file workloads. If the requirement is “no local infrastructure and no extra storage budget,” ask what approved option is supposed to meet the design team’s actual needs. There may not be a workable answer under those constraints.

One useful first step is cleanup, not platform selection. Work with the file owners to identify duplicates, abandoned projects, and versions that no longer need to be kept. Then size the real working set separately from long-term retention.

That might reduce the amount that needs premium, fast access, but it won’t by itself prove that SharePoint or Creative Cloud is suitable. Test the remaining active files and include ongoing version growth in the capacity plan.