Sometimes the right answer is azure-oss/storage-file-share.

Sometimes the right answer is not a PHP SDK at all.

And that honesty is exactly what good migration advice should sound like here.

Blob and Queue are replacements. File Share is a choice.​

With Blob and Queue, the story is fairly direct: old package out, new package in.

Azure Files is different because a lot of applications do not actually want a service SDK. They want a normal filesystem they can mount, read, write, and move through familiar I/O operations.

That means the first migration question is not "Which package replaces this package?"

It is "What problem is the app really solving?"

Choose azure-oss/storage-file-share when you need Azure Files semantics​

The package is a strong fit when your app needs Azure-aware service behavior, especially around:

• share access
• directory and file client navigation
• SAS generation
• Azure Files-specific access patterns

If that is your use case, the package gives you a modern baseline and a much healthier long-term direction than staying on the retired Microsoft SDK.

Choose a mounted share when you really want a filesystem​

If your application mostly wants to:

• open and write files like local storage
• move paths around
• let existing file APIs do the work
• treat Azure Files as infrastructure rather than business logic

then an SMB or NFS mount is often the more natural design.

That may feel less exciting than a library migration. It is often more correct.

Why this kind of guidance matters​

Teams remember when documentation helps them avoid the wrong abstraction.

If you oversell File Share as a drop-in SDK replacement for every legacy workload, people will discover the gaps the hard way. If you help them choose the right path up front, they are far more likely to trust the rest of the ecosystem.

That trust is worth more than a smoother headline.

Where to go next​

If you are evaluating the SDK path seriously, start with Migrate from microsoft/azure-storage-file.

That is the practical answer.

The more interesting answer is why the move feels bigger than a disk-driver swap.

Your old disk is sitting on an old stack​

The package may look like a thin Laravel integration, but underneath it sits a chain of legacy dependencies:

• the old Laravel driver
• the old League Flysystem Azure adapter
• the old Microsoft Blob SDK

So when teams say, "The filesystem config still works, why touch it?", they are only looking at the top layer.

azure-oss/storage-blob-laravel replaces that entire stack with a maintained Blob SDK, a maintained Flysystem adapter, and a Laravel driver designed to fit today’s framework expectations.

This is where the upgrade gets interesting​

Laravel teams usually care about three things more than package history.

1. Cleaner config​

The new driver is easier to read at a glance.

Instead of old field names and compatibility baggage, you get config that spells out its intent:

• connection_string
• account_name
• account_key
• temporary_url
• is_public_container

That sounds cosmetic until you have to audit production config across four environments and three teammates.

2. A real modern auth story​

This is the part that changes architecture conversations.

The new package supports:

• client_secret
• client_certificate
• workload_identity
• managed_identity

If your Laravel app runs on Azure, that means you are no longer trapped in the world where long-lived storage secrets feel like the only practical option.

3. URL behavior you can reason about​

Blob disks always get judged on URLs.

Not in demos, but in the awkward cases:

• public container links
• signed temporary URLs
• custom origins
• Azure Front Door in front of storage

This package gives those concerns a cleaner home instead of leaving them as half-documented quirks.

The best rollout is usually the boring one​

Start with a connection string. Keep the disk name stable. Prove uploads, downloads, Storage::url(), and Storage::temporaryUrl() still behave the way your app expects.

Then, once the migration is quiet in production, decide whether you want to modernize authentication.

That pacing matters. A good migration is not the one with the biggest ambition. It is the one your team can safely ship.

Where to go next​

For the exact config mapping and rollout checklist, read Migrate from matthewbdaly/laravel-azure-storage.

It sounds official. It sounds familiar. It sounds like the obvious thing to install.

The problem is that it is abandoned, and more importantly, it keeps your Flysystem layer tied to the legacy Microsoft Blob SDK.

That is why the modern move is not just "replace one adapter with another." It is really about getting your storage abstraction off old foundations and onto azure-oss/storage-blob-flysystem.

This is the least dramatic migration in the set​

That is good news.

If you already use Flysystem v3, this change is usually more like swapping the engine than rebuilding the car:

• the Flysystem mental model stays the same
• your app still talks to a Filesystem
• the big change is how the Azure adapter is created

So while the package name change matters, the real upgrade happens one layer down.

What improves under the hood​

The old adapter is built on microsoft/azure-storage-blob.

The new one is built on azure-oss/storage-blob, which means the adapter now inherits a storage stack that is actively aligned with the rest of this ecosystem:

• current Blob clients
• modern SAS support
• better docs for public URLs and temporary URLs
• easier handoff between direct SDK code and Flysystem-backed code

That matters any time your project stops being "just a filesystem disk" and starts needing storage-specific behavior.

The one code change to understand​

The old adapter starts with a BlobRestProxy and a container name.

The new adapter starts with a BlobContainerClient.

That is a healthier boundary. It means the adapter receives exactly the scope it needs, no more and no less. Once you see that, the migration becomes much easier to reason about.

When this migration is almost boring​

That is the sweet spot:

• you already construct the adapter in one place
• you already use Flysystem v3
• your app does not depend on odd adapter-specific behavior
• your biggest concern is URL generation and upload behavior

In that scenario, this is often a tidy refactor with a good payoff.

Why it is still worth doing​

Because abandoned infrastructure code has a way of becoming "fine" right up until the moment it is not.

If your Blob adapter is the bridge between application code and storage, it is a good place to remove uncertainty. Moving to azure-oss/storage-blob-flysystem gives you a maintained adapter on top of a maintained SDK, and that is a much better place to keep building from.

Where to go next​

For the concrete namespace, constructor, and URL behavior changes, start with Migrate from league/flysystem-azure-blob-storage.

At first glance, moving from squigg/azure-queue-laravel to azure-oss/storage-queue-laravel looks like a simple config refresh. Rename a few fields, change the driver, move on.

That is partly true. It is also how teams end up underestimating the one thing that matters most in queue code: behavior.

The package swap matters because operations matter​

The old package is tied to the legacy Microsoft Queue SDK.

The new package puts Laravel on top of azure-oss/storage-queue, which gives the queue layer a maintained base and a config model that looks more like something you would actually want to support in 2026.

That includes:

• native connection string support
• explicit shared-key config
• SAS-bearing connection strings
• custom endpoints for local and emulator-style setups

None of that is glamorous. All of it reduces friction.

The real migration question is this​

Will your workers behave the same way after the upgrade?

That is the heart of it.

Queue code is rarely judged by how elegant the config file looks. It is judged by whether jobs reappear too early, whether failed work is retried the way you expect, and whether local and cloud environments behave close enough to trust.

That is why the move to azure-oss/storage-queue-laravel is worth doing, but also why it should be treated like an application behavior change, not just dependency cleanup.

What gets better​

• config names that read clearly
• queue options like retry_after, time_to_live, and after_commit
• a cleaner path for teams that already store Azure connection strings
• one maintained queue stack from Laravel down to the SDK

That is the sort of foundation you want before your job volume goes up, not after.

Migrate it like production infrastructure​

If you make this switch, test the boring things hard:

• long-running jobs
• retries
• delayed jobs
• local development against custom endpoints or Azurite-style setups

The docs can help with the rename work. Your staging environment should validate the timing work.

Where to go next​

For the exact field mapping and worker-focused checklist, go to Migrate from squigg/azure-queue-laravel.

The old microsoft/azure-storage-blob package still has years of examples, Stack Overflow answers, and copy-pasted snippets working in its favor. But if the real question is, "What should we build on today?", the answer is much cleaner:

Use azure-oss/storage-blob.

Not because it is newer for the sake of being newer. Because it is the package that actually matches how modern PHP teams work now: current PHP, clearer clients, current docs, and a path into the rest of the azure-oss ecosystem if your app grows beyond a few direct Blob calls.

The old package usually breaks trust in slow motion​

Teams rarely wake up and schedule "The Great Blob Migration."

What usually happens is quieter:

• a PHP upgrade is overdue
• a new feature needs signed URLs or tags
• a teammate wants Laravel or Flysystem integration
• someone tries to standardize auth across Azure services

That is when the age of the old package starts to matter. It is not one dramatic failure. It is friction everywhere around the edges.

Why azure-oss/storage-blob is the right replacement​

It gives you a better center of gravity for the codebase:

• BlobServiceClient for account-level work
• BlobContainerClient for container-scoped work
• BlobClient for the blob you actually care about

That client model sounds small, but it changes the feel of the code. Instead of passing container and blob names through every method call, your code starts to model the storage structure directly.

The short comparison​

The best part of this migration is not glamorous​

The payoff is not a flashy demo.

It is that six months later you have one Blob stack instead of a museum exhibit:

• direct SDK usage on a maintained package
• Flysystem support on the same foundation
• Laravel integrations that are not built on a deprecated core
• docs that describe the package you are actually using

That is the kind of migration that keeps paying rent.

Who should move first​

You are a strong candidate for an easy first pass if:

• your app already runs on PHP 8.2+
• you still authenticate with a connection string
• your Blob usage is mostly uploads, downloads, deletes, listing, and signed URLs
• you want to keep the first migration boring and safe

That last point matters. You do not need to adopt Microsoft Entra ID, redesign your filesystem abstraction, and rewrite every storage call in one sprint. You can move the package first and modernize the rest in phases.

Where to go next​

If you want the actual code-and-config path, read Migrate from microsoft/azure-storage-blob.