Five Questions Every Enterprise Should Ask Before Their Next Modernization Project
For decades, enterprises have relied on managed file transfer (MFT) tools to move data in and out of the mainframe. These tools did their job well — they were built for a world of server-to-server transfers, scheduled batch windows, and on-premises endpoints. That world is changing.
Today, the destination is rarely another server down the hall. It is Google Cloud. It is AWS. It is Azure. It is a data lake feeding an AI model or a cloud-native analytics platform feeding the business. The volumes are larger, the timelines are shorter, and the downstream consumers are more demanding than ever.
The question enterprise architects should be asking is not whether their current file transfer tool still works. It almost certainly does. The question is whether it was designed for the job they are about to ask it to do.
Based on what we are seeing in large-scale mainframe-to-cloud initiatives — including a recent enterprise retail proof of concept involving datasets of 100 to 200 million records — here are five questions every organization should work through before committing to a mainframe data movement approach for their modernization journey.
1. Does It Understand Mainframe-Native Data Out-Of-The Box?
Mainframes do not store data the way distributed systems do. VSAM, GDG, QSAM, tape-based datasets, non-VSAM sequential files — these are the building blocks of decades of enterprise data, and they do not translate cleanly into the flat-file, row-based world that most modern tools assume.
Traditional MFT tools are very good at moving bytes from point A to point B. But moving bytes is not the same as moving data. If your tool requires custom scripting, copybook parsing, or staging gymnastics just to handle a GDG with relative generations, you are going to spend more time in pre-processing than in actual modernization.
The right question to ask a vendor: can your product read and move VSAM, GDG, and tape-based datasets with configuration alone, or does it require us to write code?
2. Can It Scale to Hundreds of Millions of Records Without Hitting a Staging Bottleneck?
Many legacy data movement tools were architected around intermediate staging — write to a local landing zone, then transfer, then clean up. That model works fine for a few million rows. It falls apart at enterprise scale.
In a recent large retail POC, PropelZ successfully processed datasets in the 100 to 200 million record range, delivering throughput that outpaced existing MFT-based approaches — in some cases by roughly 2x. Just as important, it did so without the staging overhead that historically constrains large-volume transfers.
The question to ask: what happens to your tool when the dataset doubles? When it grows tenfold? When the business needs it to run inside a tighter window?
3. Does It Support Multiple Delivery Patterns, Or Lock You into One?
Cloud modernization is rarely a single pattern. Sometimes you need data landed as files in cloud object storage so that downstream systems can consume it on their own terms. Other times you need it staged in a relational target like PostgreSQL for incremental processing. And increasingly, you need both — depending on which downstream consumer is asking.
Tools built for a single transfer pattern force enterprises into uncomfortable architectural trade-offs. Purpose-built modernization tools give you optionality. In our recent POC work, validating both a direct file-to-cloud path and a PostgreSQL staging path turned out to be critical — each approach served a different downstream need, and having both available created resilience in the overall design.
The question to ask: does your tool support multiple delivery patterns natively, or does each new pattern require a new product, a new integration, or a new custom build?
4. Is It No-Code and Configuration-Driven, Or Does It Require Development Effort?
Every hour your team spends writing scripts, maintaining copybook parsers, or debugging custom integration code is an hour not spent on modernization. Yet many traditional tools still assume a small army of mainframe developers is standing by to keep the pipes flowing.
Configuration-driven, no-code execution is not a nice-to-have. It is the difference between a project that ships on time and one that gets stuck in the weeds. It also dramatically changes the risk profile: fewer custom artifacts mean fewer things to break, fewer things to document, and fewer things to hand off when people change roles.
The question to ask: how much custom code will my team need to write and maintain to keep this solution running in production?
5. How Cleanly Does It Integrate with Cloud-Native Targets?
Here is where the gap between legacy MFT tools and purpose-built modernization tools becomes most visible. Traditional tools tend to treat the cloud as just another FTP endpoint — a place to drop a file. Purpose-built tools assume the cloud is the target architecture, and integrate accordingly.
That distinction matters in practice. It affects how authentication works. It affects how transfers recover from interruptions. It affects how the tool participates in cloud-native observability and security models. And it affects how quickly you can align with partners like your system integrators, who are almost certainly already building in the cloud.
The question to ask: does your tool integrate with cloud storage and services as a first-class citizen, or is cloud support bolted onto an architecture that was designed for something else?
Where This Leaves Enterprise Buyers
None of this is an argument that traditional MFT tools are bad. They are not. For the workloads they were designed to handle — server-to-server file transfer inside the enterprise perimeter — they remain reliable and well-understood.
The argument is simpler: the job has changed. Moving mainframe data to the cloud at modernization scale is a different problem than moving files between servers, and it deserves tools built for that problem.
Enterprises that work through the five questions above tend to arrive at the same conclusion on their own. They do not need to be sold. They need to see the criteria, apply them honestly to their current environment, and make the call.
If you are in the middle of that evaluation, we would welcome the conversation. PropelZ™ was built specifically for this moment — secure, no-code, configuration-driven movement of mainframe data to the cloud at enterprise scale.
About PropelZ
PropelZ from VirtualZ Computing is a purpose-built solution for moving mainframe data to the cloud. It supports VSAM, GDG, tape, and non-VSAM datasets out of the box, runs no-code through standard z/OS job scheduling, and delivers data to cloud targets including Google Cloud, AWS, and Azure.
Next Steps
- Schedule a PropelZ briefing.
- Watch a demo of PropelZ.
- Try PropelZ.
Learn More
- Visit our Customer Briefing Center.
- Review all VirtualZ Use Cases, Thought Leadership papers, and Solution Briefs.
- Explore our YouTube channel, podcasts, and blog.
- Still have questions? Contact us.
