I Fed AWS Transform a 1.4 KB CSV. It Built Me a Storage Business Case.

Why storage gets skipped in migration planning

Migration assessments tend to lead with servers: CPU, memory, instance families, licensing. Storage often ends up as a single line item.

That works for disks attached to VMs. It falls apart for the stuff that is not attached to anything: the NetApp filer everyone mounts, the SAN LUNs behind the Oracle box, the backup repository that has quietly grown to 15 TB, the tape library nobody wants to talk about.

AWS Transform assessments can now take that detached storage, map it to AWS services, and produce a TCO. I wanted to see what that looks like end to end, so I built a small fictional inventory and ran it.

Getting into the right track

I opened AWS Transform in Mumbai (ap-south-1). The landing page now has separate tiles for continuous modernization, app assessment, Windows, mainframe, infrastructure assessment and workload migration. There is also a banner about cross-region processing starting October 7, 2026, which is worth reading if your customer has data residency requirements.

My first question in chat was too vague, and Transform went straight into continuous modernization: connect a repo through the ATX CLI, run a modernization-readiness analysis. Useful, but wrong track. It did ask whether I meant a source-code repository or a mainframe application.

Once I asked about storage directly, the answer was clear. Storage assessment is part of the migration assessment job. Server-attached storage gets a basic estimate automatically in every migration assessment. Detached storage (file, block, object) needs its own input.

The inputs it listed were an RVTools export or a NetApp DII export (zipped CSV query results, with different queries for NAS and SAN). I had neither. I had a CSV. More on that in a second.

I asked it to create a workspace called Assessment, then a migration assessment job. Both happen through chat with a confirm button. The job came up as MigrationAssessmentV2-2026-10-22-0946 with a two-step plan on the left: Import inventory and Generate Migration Business Case.

The line that caught my eye was "You can upload the files in any format." I took that literally.

The inventory I uploaded

Nine volumes, 80 TB used in total: three NAS shares, three SAN LUNs, three backup or archive stores. One flat CSV, 14 columns, nothing from the official template.

# techcorp-storage-inventory.csv (first rows)
asset_id,storage_category,storage_type,source_system,protocol,application,environment,
provisioned_tb,used_tb,peak_iops,peak_throughput_mbps,access_pattern,retention,ha_requirement
NAS-001,File,NAS,NetApp FAS8200,NFSv4,Engineering shared drives,Production,10,8,6000,400,...
SAN-001,Block,SAN,Dell EMC Unity XT,Fibre Channel,Oracle ERP database,Production,6,5,25000,800,...
BACKUP-002,Object,Archive,LTO-8 tape library,Tape,Compliance archive,Production,30,25,0,0,...

I also put in columns I expected Transform to care about: ha_requirement (Multi-AZ for production) and retention. Keep those two in mind.

Discovery and the scenario plan

Ingestion ran in the background while the chat stayed usable. Once it finished, the Summarize inventory panel showed all nine volumes, typed correctly as file, block and object, with TB converted to GiB (10 TB became 10,240 GiB). No template, no complaints.

Then it proposed a scenario. This is the part worth slowing down on, because every number in the final TCO comes from here.

FSx for NetApp ONTAP: 6 volumes

All three NAS shares and all three SAN LUNs went to FSx for NetApp ONTAP. Not EBS. Transform's own explanation earlier in the chat said block storage maps to EBS, so this is worth noticing.

S3: 3 volumes, plus a TCO across all 9

The backup and archive stores went to S3 with a fixed class split: 20% Standard, 30% Standard-IA, 50% Glacier Instant Retrieval. The backup repository split is on, so volumes over 2 TiB keep a 100 GiB landing zone. The on-prem side gets 40% hardware, 25% software and 50% storage discount rates.

Data quality passed with no exclusions. Transform also offered an optional Cloud Economics assessment (staff productivity, resilience and agility benchmarks).

Small friction here. I typed "do cloud economics assessment". Transform replied asking me to confirm I wanted to proceed without it, and I answered "yes do". The confirmation was phrased the opposite way to my request, so be explicit in chat when you confirm something.

The result

On paper that is roughly 7x cheaper on AWS. FSx ONTAP is about 79% of the AWS total, covering 30 TB of file and block, including the 25,000 IOPS Oracle volume. The 50 TB of backup and archive comes to under $8K a year in S3.

The chat breakdown lists the support line under "Cloud Economics". The PDF and the deck call it Business Support: $6,149, which is 10% of the storage cost.

Where the $475,820 comes from

The deck has a 5-year cash flow slide, and that is where the on-prem number makes sense. Year 1 carries the hardware. Years 2 to 5 do not.

$2,379,100 over five years is exactly $475,820 a year. So the annual on-prem figure is a 5-year average with a Year 1 purchase inside it. Year on year after that, the comparison is $168,000 on-prem against $67,640 on AWS.

The deck's on-prem slide says the estimate uses industry average benchmark costs on a 5-year hardware refresh cycle, and that it excludes employee costs, migration tools and professional services. My CSV had no on-prem cost data at all, so every on-prem number here is Transform's benchmark.

Where the FSx money goes

The workbook's FSxN-Cost-Summary sheet breaks the $53,530 down per storage array. Transform grouped the volumes by array name, so SAN-001 and SAN-002 (both on the Dell EMC Unity XT) became one file system. That is why the PDF says 5 arrays for 6 volumes.

Every file system got 384 MiB/s of provisioned throughput at $614.40 a month. Across five file systems that is $36,864 a year, about 69% of the FSx cost. Capacity is the smaller part of this bill. The 30 TiB used on-prem comes out as 20,514 GiB of FSx capacity in the workbook.

And the S3 side

The Object-S3-Detail sheet shows all three volumes on "Default Allocation", a 16,384 KiB average object size, and zero daily PUTs and GETs. None of that was in my CSV, so those are Transform's fill-ins too.

What you get to download

Reports arrived as a zip plus an error_file.csv, both in the job's Artifacts tab.

Inside the zip:

• analysis.xlsx (35 KB): eight sheets for this run. Read Me, Glossary, File-FSxN, Block-FSxN, FSxN-Cost-Summary, Object-S3, Object-S3-Detail and Assessment Issues. The Read Me also describes EBS, EFS, FSx for Windows, Lustre and OpenZFS sheets, which were not part of this export.
• business_case.pptx (4.9 MB): 38 slides. Executive summary, scope, TCO, the 5-year cash flow, one pricing slide per FSx array, the S3 breakdown, next steps and an appendix on FSxN configurations, DataSync and support plans.
• report.pdf (66 KB): four pages. Executive summary, financial summary, storage findings, recommendations and assumptions.

The PDF's assumptions section spells out exactly how the numbers were built: 80% usable SSD, 16% system space, 3% metadata, 5% snap reserve, 50% simultaneous peaks, 10% API overhead on S3, and a 100 GiB gp3 landing zone for the backup repository.

Two things in that page matter. The 45% compression and dedupe saving is a default applied when your data does not include it, and mine did not. And the recommendation text points you to the error file before treating the estimate as final.

The PDF's executive summary also lists strategic benefits like savings "with Reserved Instances" and moving to "right-sized EC2 instances". This assessment had 0 servers in scope and $0 compute. Edit that table before the report goes to anyone.

The error file

error_file.csv has six rows, one for each FSx volume, all at WARNING severity. Each one says the inventory reported no average latency, so Transform substituted a 2.0 ms default and costed the volume from it. The same six rows are in the workbook's Assessment Issues sheet. The three S3 volumes have no warnings.

My CSV had peak IOPS and throughput but no latency column. Adding avg_latency_ms per volume is the fix it asks for, followed by a re-run.

Notes if you try this yourself

• Ask for a migration assessment job by name. My vague first prompt went to continuous modernization.
• A clean CSV works. You do not need the template or DII to try it, but extra columns like HA and retention are not guaranteed to be used. Set those in the scenario through chat.
• Treat the first scenario as a baseline. Run a second one with Multi-AZ production, higher peak percentile and realistic archive tiers, then compare.
• Open error_file.csv first. In my run it flagged all six FSx volumes for missing average latency. Include an avg_latency_ms column up front.
• Read the 5-year cash flow slide before quoting the annual on-prem number.
• Do not sign in as root. I did for this test. Use an IAM Identity Center user for anything real.
• Check the cross-region processing banner if your customer has residency rules, even when the workspace is in their region.