A customer hands over raw front-end numbers at kickoff: 2 PB of VMs and file systems to protect, growing 30 percent a year, and expects one Data Domain system to hold it all. An engineer is about to choose a platform tier. Why must those raw front-end estimates be translated before a platform can be selected?

Front-end capacity is the source data presented for protection, while the appliance footprint is what remains after DD OS applies inline variable-length deduplication and compression during ingest. Sizing therefore converts each data type's raw estimate through an expected dedupe and compression ratio, adds retention, growth and any replication copies, and then checks the answer against the platform's usable capacity so the system stays well below the utilization point where ingest performance degrades. Matching raw bytes one-for-one fails as a method because it assumes zero reduction and buys physical capacity the customer will never fill. Deriving the tier from a growth percentage alone fails because the percentage applies to a post-dedupe base that differs per data type, so a rate without a stated ratio has no meaning. Scoping the platform choice to enabled protocols fails because protocols shape interface and network design, not capacity. Exam caveat: expected ratios are per-workload averages, and encrypted or already-compressed sources can shrink the benefit close to one-to-one. Operational check: rebuild the sizing worksheet from the customer's raw estimate, document the ratio used per data type, and confirm the selected tier still keeps usable utilization within the documented ceiling after five years of growth.