STREAM FILES STRAIGHT TO AZURE AND S3 FROM IBM MQ MFT - NO STAGING, NO SCRIPTS
Your managed file transfer flows are increasingly asked to land data somewhere they were never designed to reach: cloud object storage. Data lakes, analytics pipelines, long-term archives, partner exchange buckets more and more of it lives in Azure Blob Storage and Amazon S3, not on a filesystem.
But IBM MQ Managed File Transfer was built to move files to and from disk and queues. Bridging that last hop to the cloud usually means bolting extra machinery onto a platform you chose precisely because it was reliable: staging directories, post-transfer upload scripts, scheduled sync jobs, and a second set of things to monitor and fail. Every one of those is a new place for a transfer to silently break.
We built the MQAttach Cloud Storage IO Exit to remove that seam entirely. It ships as part of the MQAttach MFT Extension Pack, free of charge to customers running the IBM MFT Module of the IntegratD stack.
Cloud object storage as a native MFT destination
The exit plugs into your existing MQ MFT agents and lets them treat a blob container or S3 bucket as a first-class transfer source and destination the same way they already treat a directory. A transfer writes to cloud://… and the bytes stream directly from the agent to the object store.
There is no intermediate disk staging. Nothing lands locally to be picked up and re-uploaded later, which means no staging volumes to size and manage, no cleanup jobs, and no second hop where a file can get stuck. It works in both directions, file to blob, blob to file, and blob to queue, and supports wildcard transfers and resource monitors against bucket prefixes, so your existing transfer patterns carry over.
Correct by construction, not by convention
This is the part architects tend to care about most. Downstream consumers of a bucket the analytics job, the partner, the archive index, must never see a half-written object. The exit guarantees they can’t.
Writes use a two-phase model: data is staged invisibly and becomes visible only at a single atomic commit when MFT closes a successful transfer. A failed or interrupted transfer discards the staged data rather than exposing a partial file. Overwrite protection is enforced atomically at commit. The result is that a consumer either sees the complete object or sees nothing at all, there is no partial-file state to defend against downstream. Crash recovery restarts cleanly and re-verifies the transfer rather than resuming into an inconsistent object.
One exit, multiple clouds
The exit is multi-cloud by design. Azure Blob Storage, Amazon S3, and S3-compatible stores such as MinIO are supported today through pluggable providers, and additional backends are drop-in additions rather than a new product. If your estate spans more than one cloud — or you expect it to you standardize on one exit and one operational model instead of a different integration per provider.
Security that fits how your teams already work
Credentials are configured per profile and never hardcoded. The exit supports connection strings, SAS tokens, and managed identity on Azure, and IAM roles or the standard credential chain on AWS, with secrets resolved from environment or file references rather than sitting in config. Authorization is enforced by your cloud provider’s IAM at the moment of I/O, under each profile’s own identity so cloud access is governed by the same controls your security team already audits.
Per-profile retry and circuit-breaker thresholds are tunable, so a slow or unavailable backend degrades predictably instead of hanging a transfer indefinitely.
Extends your investment instead of replacing it
For teams evaluating this commercially, the point is that nothing gets ripped out. The exit deploys onto your existing agents and reads a single configuration file which you can keep locally per agent or manage centrally on the IntegratD server, so cloud profiles for a whole fleet of agents live in one place. You keep your MQ MFT topology, your operational runbooks, and the reliability guarantees you already depend on and you gain native cloud storage without adopting a separate platform to run alongside it.
Existing MQAttach MFT Extension Pack instruction sets keep working exactly as before, too adding a cloud source or destination doesn’t change or disable anything you already run.
See it in your environment
If your MFT flows are heading for the cloud, the MQAttach Cloud Storage IO Exit is the shortest path there that keeps MQ MFT doing what it does best.
Book a demo to see it stream into your own Azure or S3 target, or contact sales@mqattach.com to talk through your estate and licensing.
IntegratD for MQ Managed File Transfer (MFT)
IntegratD for MQ Managed File Transfer (MFT) is a secure, scalable solution designed to streamline and automate the exchange of critical data across your entire ecosystem. Whether transferring files between applications, headquarters, distribution centers, stores, workforce, customers, or trading partners, IntegratD for MQ MFT ensures reliability, compliance, and end-to-end visibility. With robust security features and seamless integration, our solution empowers businesses to optimize workflows and enhance operational efficiency.