Start with the simple idea, then build up the picture slowly.

A data movement tool is a program whose job is to copy data from one place to another. The places may be your own computer, a file server in your office, an Azure storage account, or even a storage service run by another cloud company. The program reads the data at the source, sends it across the network, and writes it at the destination, while taking care of the awkward details such as retries, speed, and checking that nothing was damaged on the way.

Azure provides two of these tools that almost every Azure user meets sooner or later. AzCopy is a small command-line program. A command line is a text window where you type instructions instead of clicking buttons. AzCopy is built for speed, for large amounts of data, and for automation, which means running the same job again and again without a person clicking. Azure Storage Explorer is a desktop application with windows, folders, and buttons. It lets you see what is inside your storage accounts and drag files in and out, much like using the file manager on your own computer.

Before going further we should name the place where the data lives. Azure keeps files and objects in a storage account, which is a top-level container in Azure that holds several kinds of storage. The kinds that matter in this guide are Blob storage, which stores objects such as pictures, backups, and logs inside containers, and Azure Files, which stores shared folders that computers can mount like a drive. Both tools understand these two kinds, and Storage Explorer also understands a few more.

It is important to see what these tools are not. They are not databases, and they are not backup products with schedules built in. They do not change the data they carry. They simply move it, faithfully and efficiently. What you decide to move, when, and how often is up to you, and good planning around the tools matters as much as the tools themselves.

To see why good tools matter, picture what goes wrong without them.

Copying one small file from your laptop to a server is easy. Copying five million files totalling several terabytes over an office internet link is a different story. A terabyte is about a thousand gigabytes, roughly what a thousand hours of high-quality video would need. At that size, everything that is rare for small jobs becomes normal: the network drops for a moment, a laptop goes to sleep, a file is changed while it is being copied, and a single error in the middle of the night can ruin a transfer that has already run for ten hours.

The slow, fragile way

Some people try to move data with ordinary drag and drop in a file manager, or with a simple copy program. These work for small jobs, but for big ones they have serious weaknesses. They usually copy one file at a time, which leaves most of the network bandwidth unused. They do not know how to resume neatly after an interruption, so a failure means starting again. They give little useful report on what succeeded and what failed. And they were not designed to talk to cloud storage, so they often cannot be used for this purpose at all.

Why the cloud changes the problem

Cloud storage speaks through web requests over the internet. Each file becomes one or more requests, and each request has a small fixed delay. If you send them one at a time, the delays add up to a lot of waiting. The solution is to send many requests at once, which is called parallelism. A good data movement tool opens many connections and keeps them busy, so that the network link, rather than the tool, becomes the limit.

Why safety matters

Data is valuable, and moving it creates risk. A careless copy can overwrite newer files with older ones, delete things that should have stayed, or leave a half-finished mess. Good tools offer protective features such as a practice mode that shows what would happen without doing it, careful rules for replacing existing files, and checks that confirm the copy matches the original.

Every tool exists because somebody had a painful problem. Here are the main ones.

One-time migration

A company retires its old file server and wants everything in Azure by Monday. This is a migration, a one-time move of a large body of data. AzCopy is ideal here because it is fast and can resume if the weekend brings trouble.

Ongoing synchronisation

Another team needs a folder on a local server to stay matched with a container in Azure, with new and changed files copied across every night. This is synchronisation, keeping two places in step. AzCopy has a dedicated mode for this, so only the differences travel, which saves time and money.

Everyday browsing and small fixes

A developer needs to look inside a container, delete a test file, upload a single configuration file, or check which version of a file is stored. Writing a command for each of these small tasks is slow. Storage Explorer lets them do it in a few clicks.

Seven building blocks. Learn these and the rest of the topic becomes easy to follow.

Source and destination

Every transfer has a source, which is where the data comes from, and a destination, which is where it goes. Either can be a local folder, a container in Blob storage, a share in Azure Files, or, for AzCopy, certain storage services of other cloud providers. Naming both clearly is the first step of every job.

Blob containers and file shares

A blob is one stored object, such as a picture or a backup file. Blobs live in containers, which are like top-level folders. A file share is a shared folder in Azure Files that can be mounted on computers. The tools treat these a little differently because blob storage is really a flat list of names, while file shares have true folders.

Authentication

Authentication means proving who you are. Azure storage will not let anyone read or write without it. The two main ways in these tools are signing in with your work account through Microsoft Entra ID, and using a shared access signature, called a SAS, which is a specially built web address that grants limited access for a limited time.

Authorisation and roles

Authorisation means checking what you are allowed to do after you have proved who you are. Azure uses roles, which are named bundles of permissions. For example, one role allows reading blobs and another allows writing them. A person may sign in successfully and still be refused because they lack the right role.

Jobs and transfers

In AzCopy, each command you run creates a job, which is a unit of work with an identity number. A job is split into many small transfers, usually one per file or per piece of a large file. AzCopy records the plan of the job on disk, which is what makes resuming possible.

Copy versus sync

A copy sends everything you name and may replace what is already there, depending on the rules you set. A sync compares source and destination and moves only the differences, making the destination match the source. Sync is one-directional: it makes the destination look like the source, not the other way round.

Server-to-server transfer

When both the source and the destination are in Azure storage, AzCopy can ask the destination to fetch the data directly from the source, without the data passing through your computer. This is called a server-to-server copy. It is very fast, and your own internet link is barely used.

How the pieces fit together, from your computer to the storage account.

Look at the diagram below from left to right. On your side are the sources, such as local disks, office file servers, and perhaps another cloud. In the middle sit the two tools. On the Azure side is the storage account, with its blob containers and file shares. The tools talk to Azure over the internet or over a private network link, using web requests, after you have proved your identity.

flowchart LR
    LD["Local disk"] --> AZ["AzCopy"]
    FS["Office file server"] --> AZ
    OC["Other cloud storage"] --> AZ
    SE["Storage Explorer"] --> AZ
    AZ --> AUTH["Microsoft Entra ID or SAS token"]
    SE --> AUTH
    AUTH --> NET["Internet or private network link"]
    NET --> SA["Storage account"]
    SA --> BC["Blob containers"]
    SA --> FSH["Azure Files shares"]

AzCopy as one small program

AzCopy is delivered as a single program file that you download and unpack. It does not need a long installation, and it works on Windows, Linux, and macOS. Because it is a command-line program, it can be placed inside scripts, scheduled jobs, build pipelines, and automation tools. It is written to be fast and to use the computer’s processor and network connection efficiently.

Storage Explorer as a desktop app

Storage Explorer is a normal desktop application that you install, available for Windows, macOS, and Linux. It shows a tree on the left with your accounts, containers, and shares, and a list on the right with the contents. You can sign in with your Azure account, or connect using a connection string or a SAS. When it moves large amounts of data for blobs and files, it relies on AzCopy behind the scenes, so the two tools share the same strong transfer engine.

What Microsoft manages and what you manage

Microsoft manages the storage service, its hardware, and its copies of your data. Microsoft also publishes and updates both tools. You manage the computer that runs the tools, the network link, the identities and permissions, the scripts, and the choices about what to move and when. This is the shared responsibility model, and it means that a slow transfer is often about your computer or your network, not the storage account.

What happens between “I press enter” and “the files are in Azure”.

When you run an AzCopy command, the program first understands what you asked: the source, the destination, and the rules such as whether to include subfolders. It then starts scanning, which means listing the files at the source and, for sync, at the destination. While scanning, it builds a plan, which is a list of all the transfers that must happen. This plan is saved to disk in a small set of files, so that if the job stops, the program remembers what was planned and what was already finished.

Splitting big files into blocks

Large files are not sent as one huge piece. Blob storage accepts big files as a series of smaller blocks, and AzCopy sends many blocks at the same time. When all blocks have arrived, it asks Azure to join them into the final file. This is faster, and it also means that if one block fails, only that block must be sent again instead of the whole file.

Parallel workers

AzCopy runs many worker threads at once. A thread is a small line of work inside a program, and many threads together let the program do many things at the same time. The number of parallel connections is chosen automatically based on the computer, and you can change it if you need to slow it down or speed it up. The aim is to keep the network busy without overwhelming the computer or the storage account.

flowchart TD
    CMD["You run a command"] --> SCAN["Scan source and destination"]
    SCAN --> PLAN["Build job plan and save to disk"]
    PLAN --> SPLIT["Split big files into blocks"]
    SPLIT --> WORK["Many parallel workers send pieces"]
    WORK --> RETRY{"Did a piece fail?"}
    RETRY -->|"Yes"| AGAIN["Retry the piece with a delay"]
    AGAIN --> WORK
    RETRY -->|"No"| JOIN["Azure joins blocks into final files"]
    JOIN --> SUM["Print summary and write log"]

Retries and the busy signal

The network is not perfect, and the storage service sometimes says it is busy, which is its way of asking callers to slow down. AzCopy handles both by retrying failed pieces after a short wait, and by increasing the wait when trouble continues. This is why a job can survive a short network drop without human help. If a piece keeps failing, it is reported as failed in the summary, and you can resume the job to try the failed pieces again.

The logs and the plan files

AzCopy writes log files and job plan files into a folder in your user area. The logs describe what happened, which is invaluable for finding out why a particular file failed. The plan files are what make the resume feature work. Because these files take disk space over time, there is a command to clean up old jobs once you no longer need them.

The life of a data movement project, from planning to cleaning up.

A transfer project has a lifecycle, which is simply the series of stages it passes through. Skipping a stage is the usual cause of trouble. The most common error is to go straight to running the big transfer, without planning permissions, testing with a small sample, or deciding how success will be checked.

flowchart LR
    A["Plan what and how much"] --> B["Prepare accounts and permissions"]
    B --> C["Test with a small sample"]
    C --> D["Run the full transfer"]
    D --> E["Verify the result"]
    E --> F{"Everything matches?"}
    F -->|"No"| G["Resume or fix and retry"]
    G --> E
    F -->|"Yes"| H["Clean up tokens and logs"]

The path of a single file

Follow one file as it travels. AzCopy opens it on your disk, reads it in blocks, and sends the blocks as web requests over an encrypted connection to the storage account. The storage service writes each block, then, when told, joins them into one blob. The final blob appears in the container with the name and folder-like path you asked for. At every step, the tool can tell exactly which blocks have been accepted, so an interruption never loses track of progress.

The visual side of Azure storage, and the things it does well.

Storage Explorer is designed so that a person who has never typed a command can still work with Azure storage. After you sign in, it lists your subscriptions and storage accounts. Opening an account reveals its containers, shares, and other items. Opening a container reveals its blobs and folders, just like opening a folder on your own computer.

What you can do with it

Other storage types

Besides blobs and files, Storage Explorer can also show queues, which hold small messages for programs to process, and tables, which hold simple structured records. It can also open data lake storage, which is blob storage organised with true folders for analytics, and some other Azure data services. This makes it a convenient single window for many kinds of Azure data.

The emulator for developers

Developers often test their programs against a storage emulator, a small program on their own computer that pretends to be Azure storage. This lets them test without spending money or touching real data. Storage Explorer can connect to such an emulator, so the developer can look at the test data with the same tool they use for real accounts.

The limits of a visual tool

Storage Explorer is ideal for people and for modest jobs. It is not the best choice for scheduled, unattended work or for very large, carefully tuned migrations, because clicking cannot be repeated automatically and cannot easily be placed inside a script. For those cases AzCopy, the engine underneath, is the better tool to use directly.

Choosing how to prove who you are is the most important security decision.

Signing in with Microsoft Entra ID

Microsoft Entra ID is Microsoft’s identity service, the system that holds your work account. In AzCopy you sign in with a login command, which opens a page where you enter your account details. In Storage Explorer you add your Azure account in a sign-in window. After signing in, your permissions depend on the roles assigned to you. This is the preferred approach for people because the access can be reviewed, limited, and removed centrally, and nothing secret has to be copied around.

For the right permissions, a person who uploads blobs needs a role that allows writing blob data, and a person who only downloads needs a role that allows reading blob data. Having broad management rights over the account is not the same thing. A common surprise is that an account owner can manage the account settings but still cannot read the data until a data role is assigned.

Signing in for automation

For scripts that run without a person, there are two common approaches. A managed identity is an identity that Azure itself gives to a resource, such as a virtual machine, so that the machine can sign in without any stored password. A service principal is an application identity with its own secret or certificate. Managed identity is the safer choice when the script runs inside Azure, because there is no secret to leak.

Shared access signatures

A shared access signature, or SAS, is a token added to a storage address that grants specific permissions for a specific time. For example, it can allow only reading, only on one container, only until tomorrow evening, and only from one network address. A SAS is handy when you must give a person or a program limited access without creating an identity for them.

Kinds of SAS

A SAS can be signed in different ways. One kind is signed with the account key, so anyone who can produce it effectively uses the master key. Another kind, the user delegation SAS, is signed with Entra ID credentials and is tied to the person who created it, which is generally the safer option. Use short lifetimes for either kind, and prefer the delegation kind when the tool or scenario supports it.

What makes transfers fast or slow, and what they cost.

The four limits

A transfer is only as fast as its slowest part. There are four places a limit can appear. First, the network link between your computer and Azure: a link of 100 megabits per second can carry at most about 45 gigabytes in an hour, no matter how good the tool. Second, the source disk, which must read the files quickly enough. Third, the computer, whose processor and memory must keep up with many parallel connections. Fourth, the storage account itself, which has limits on requests and data per second.

Many small files versus a few large files

One million tiny files and one large file of the same total size behave very differently. Each small file needs its own set of requests, and the fixed delay of each request dominates. A large file is split into blocks and moves at full speed. If you have millions of small files, expect a lower data rate, and consider whether packing them into a few archive files first would make sense for your case.

Placing the tool close to the data

Distance adds delay. Running AzCopy on a virtual machine inside Azure, in the same region as the storage account, avoids the slow public internet for the last part of the journey. For server-to-server copies between two storage accounts, the data does not pass through your computer, so you can start the job from anywhere and let Azure do the heavy lifting.

Tuning options

• Concurrency. The number of parallel connections can be raised on a strong machine and lowered on a weak or shared one.
• Bandwidth cap. A cap on megabits per second protects office users from a transfer that would use the whole internet link during working hours.
• Block size. Larger blocks can help with very large files, within limits Azure allows.
• Benchmark mode. AzCopy includes a benchmark command that uploads and downloads generated test data so you can measure what your link and account can really do before the real job.
• Filters. Include and exclude patterns let you skip unwanted files, such as temporary files, and so save time.

What it costs

The tools themselves are free. The costs come from Azure. Storing data costs money each month. Many operations, such as listing and writing millions of tiny files, are billed per batch of operations. Data leaving Azure to the internet is generally charged, while data coming in is generally not. Copying between regions can also incur charges. Prices and rules differ by region and storage type, so check the current Azure pricing pages and the pricing calculator rather than assuming.

Transfers fail sometimes. Good habits make failure boring.

Resuming a job

Because AzCopy saves a plan for each job, an interrupted job can be resumed. You list the recent jobs, find the one that stopped, and ask AzCopy to continue it. It skips what is already finished and retries what failed or never started. For safety, you will need to supply the access token again when resuming, because it is not stored with the plan.

Overwrite rules

When a file with the same name already exists at the destination, the tool must decide what to do. The overwrite rule lets you choose: always replace, never replace, ask each time, or replace only if the source is newer. This single choice protects you from the nightmare of old files wiping out new ones, so decide it deliberately for every job.

Practice mode

AzCopy offers a dry run option, which prints what would be copied, replaced, or deleted without actually doing it. Reading that list takes a few minutes and can save days of repair. This is especially valuable for sync jobs that may delete files at the destination.

How sync decides what to move

The sync command compares the files at the source with those at the destination, typically using the last modified time. Files that are missing or changed at the destination are copied. Optionally, the sync can also delete files at the destination that no longer exist at the source, so that the two places match exactly. That deletion option is powerful and dangerous, so use it with the practice mode and, ideally, with soft delete turned on at the destination.

flowchart TD
    S["Start sync job"] --> L["List source and destination"]
    L --> C{"File exists at destination?"}
    C -->|"No"| N["Copy file to destination"]
    C -->|"Yes"| M{"Source newer or different?"}
    M -->|"Yes"| O["Replace file at destination"]
    M -->|"No"| K["Skip file"]
    N --> X{"Delete extra destination files enabled?"}
    O --> X
    K --> X
    X -->|"Yes"| D["Remove files not present at source"]
    X -->|"No"| F["Finish and print summary"]
    D --> F

Verifying the result

After a transfer, check that the destination is complete and correct. Compare the number of files and the total size. Review the job summary for failed items. AzCopy can compute and store an MD5 fingerprint, a short code that identifies the exact content of a file, when uploading, and can check it when downloading, so that damaged files are flagged. For important data, open a sample of files at the destination and make sure they look right.

Protecting the destination

Before running large transfers into a container that already holds data, consider turning on soft delete and versioning for that storage account. These features keep earlier copies of replaced or deleted blobs for a period, so an accidental overwrite can be undone. Redundancy settings protect against hardware failures, but only versioning and soft delete protect against your own mistakes.

Data in motion is data at risk. Protect the journey and the keys.

Security for data movement has several parts. Who may run transfers, which is identity and roles. From where they may connect, which is networking. How the data travels, which is encryption in transit. And what is left behind, such as tokens, logs, and temporary copies.

Encryption

Both tools talk to Azure over secure web connections, so data is encrypted while it travels. Azure also encrypts data at rest on the storage account. If your organisation requires its own keys for at-rest encryption, that is set on the storage account and the tools simply work with it.

Network rules

A storage account can be set to accept connections only from certain networks. If your computer is outside the allowed list, the tools will be refused even when your identity is fine. The fix is to allow your network address, to use a private endpoint reachable from your network, or to run the tool from a virtual machine inside the allowed network. Plan this before a migration weekend, not during it.

Protecting tokens and logs

A SAS token is a secret. Do not paste it into chat messages, tickets, or documents. Do not save it in scripts that are stored in shared folders or source code repositories. Remember that command history and log files may record it. Choose short expiry times so that a leaked token becomes useless quickly.

Security checklist

• Prefer Entra ID or managed identity over SAS tokens, and avoid account keys.
• Use least privilege. Give only the roles needed, only on the containers needed, for only as long as needed.
• Set short SAS lifetimes and limit them by permission, resource, and network address where possible.
• Restrict the network using firewall rules or private endpoints.
• Keep tools updated so you receive security fixes.
• Clean up temporary access, test containers, and old logs after the project.
• Audit access using the storage account’s logs so you can see who moved what.

You cannot fix what you cannot see. Here is where to look.

Monitoring means watching the health and progress of a job. Logs are written records of what happened. There are three useful places to look: AzCopy’s own console output and log files, the Storage Explorer activity panel, and the Azure Monitor data about the storage account.

AzCopy output and logs

While a job runs, AzCopy prints a regular progress line showing how many files are done, how many failed, how many are pending, and the current speed. When it ends, it prints a summary with totals and a status. Log files record each failed item with the reason, such as “access denied”, “network error”, or “server busy”. The log level can be made more or less detailed. The job-listing commands show past jobs and their status, and a separate command can show the failed pieces of a chosen job.

Storage account metrics

Azure Monitor shows how busy the storage account is. The numbers to watch are the number of requests, the amount of data in and out, the response time, and the rate of errors and throttled requests. A rise in server-busy responses during a transfer means the account is being asked to do more than it comfortably can, and slowing the transfer down will usually help.

Troubleshooting step by step

AzCopy and Storage Explorer are two choices among several. Compare before you decide.

Azure offers more ways to move data than these two tools. The right one depends on how much data there is, how fast your network is, and how much management you want. Here are the main members of the family, described in general terms.

The availability and exact features of the managed services change over time, so check the current Microsoft documentation for each before you design around it.

A simple decision guide

flowchart TD
    Q1{"Is it a quick look or a few files?"} -->|"Yes"| SE["Use Storage Explorer or the portal"]
    Q1 -->|"No"| Q2{"Is the data huge and the network slow?"}
    Q2 -->|"Yes"| DB["Consider a physical Data Box device"]
    Q2 -->|"No"| Q3{"Need scheduled pipelines across many systems?"}
    Q3 -->|"Yes"| DF["Consider Data Factory"]
    Q3 -->|"No"| AC["Use AzCopy"]

Rules of thumb on size and time

To judge whether a network transfer is practical, do a simple sum. Divide the data size by your usable bandwidth. A hundred terabytes over a link that sustains one gigabit per second needs roughly nine days of non-stop transfer in the ideal case, and real life is slower. When the sum gives weeks or months, physical shipping becomes attractive. When it gives hours or days, AzCopy is usually the simplest and cheapest answer.

Every design choice gives something and takes something. Be honest about both sides.

The central trade-off

The big trade-off is control versus convenience. AzCopy gives you detailed control and scripting power at the cost of learning its options. Storage Explorer gives you convenience and visibility at the cost of repeatability. Managed services give you scheduling and tracking at the cost of extra setup and extra charges. A good architect chooses the lightest tool that meets the real need.

Speed versus safety

Turning every setting up for maximum speed can overload your machine or the storage account, and skipping the checks saves time at the risk of unnoticed damage. Sensible teams accept a little slower job in return for a dry run, a verification step, and a safe overwrite rule.

Simplicity versus automation

A person clicking in a visual tool is simple, but it relies on that person’s time and memory. A script is more work to write the first time, but it can run reliably every night, and it documents exactly what was done. For anything repeating, automation usually wins in the end.

Proven shapes to copy, and common shapes to avoid.

Patterns that work

Anti-patterns

An anti-pattern is a common solution that looks sensible but causes trouble. Here are the usual ones.

A practical list you can print and keep next to your desk.

Best practices

• Plan with numbers. Estimate size, file count, and bandwidth, and work out how long the move will take before you start.
• Test small first. Move a sample that includes your trickiest files before the full job.
• Use the practice mode for every job that replaces or deletes anything.
• Choose the overwrite rule deliberately. Never leave it to chance.
• Prefer identity over secrets. Use Entra ID or managed identities, and short-lived limited tokens otherwise.
• Run close to the data. Use a machine in the same region, or server-to-server copies.
• Protect the destination. Turn on soft delete and versioning before large writes.
• Cap bandwidth in office hours so people still get their work done.
• Verify and keep logs. Check counts and failures, and keep the logs until sign-off.
• Keep tools updated and download them only from official sources.
• Clean up. Remove temporary tokens, test data, and old job files when the project ends.

Common mistakes

Four typical situations, described as illustrative examples, showing how the tools are used together.

The stories below are illustrative composites of the kinds of situations where teams commonly use these tools. They are not claims about any particular company, but they reflect the reasoning real architects use.

Short answers to the questions beginners ask most often.

Everything important, in one place.

AzCopy and Storage Explorer are the two everyday tools for moving and managing data in Azure storage. AzCopy is the fast, scriptable, resumable command-line engine for bulk transfers and repeatable syncs. Storage Explorer is the friendly desktop window for browsing, small transfers, and quick management. Both sign in through Entra ID or limited tokens, both protect data in transit, and they share a strong transfer engine, so you can use them together without conflict.

Remember the comparison we began with: a removal crew and a person with a clipboard. A good move needs both, plus a plan. Count what you are moving, test a small box first, give the crew only the keys they need, watch the work, and check the new house before you hand back the keys to the old one. Follow those habits and your data will arrive complete, safe, and on time.