EXFO Replaces Dropbox, Egnyte, and ShareFile With Files.com for 30 GB ISO Delivery

EXFO builds the test, monitoring, and analytics equipment and software that telecom networks are built and maintained with. Network operators and equipment manufacturers use its instruments to validate infrastructure and monitor live networks. From its Quebec City headquarters, roughly 1,500 employees serve customers worldwide.

An EXFO instrument is hardware wrapped around software. Its embedded software must be updated and bug-fixed in the field, and shipping an update means shipping a full product ISO image, up to 30 GB, to wherever the customer’s hardware sits. With an install base spread around the world, that delivery is not an occasional favor. It is a standing operation of the business. To standardize it, EXFO replaced Dropbox, Egnyte, and ShareFile with Files.com as its delivery layer for customers, partners, and engineering teams.

Every 30 GB Delivery Was Arranged From Scratch

For years, that operation ran on improvisation. When a customer needed an update or a bug fix, someone in Customer Support or development had to get a multi-gigabyte image to them, and the channel was worked out fresh each time. Delivery ran across a spread of sharing tools: Dropbox, Egnyte, and ShareFile, used interchangeably, alongside Microsoft SharePoint and OneDrive. Whichever tool fit that customer and that engagement carried that transfer.

The cost landed at the worst possible moment. A customer with instrument hardware waiting on a fix in the field was ready to receive it, and the first step was not sending the fix but figuring out how to send it. General-purpose sync and collaboration tools were never built for the workload anyway: a 30 GB image headed to another continent is a different job from a shared folder of documents. And the customer path was only part of it. External vendors and partners had no consistent channel. Engineering teams moving ISOs and in-development modules between sites had no standard path either. Accounts, credentials, and activity records sat scattered across five products, with no single place to answer who sent which image to whom.

Three Kinds of Recipients, and No Tool That Served All Three

The sprawl was not carelessness. It was the shape of the problem. EXFO did not control the receiving end of any of these transfers. An engineer at a network operator downloaded through a browser and would not install anything to receive a file. A vendor’s system spoke SFTP. An engineering site wanted programmatic exchange between build environments. Each sharing tool covered one slice of that spectrum, so tools accumulated one recipient type at a time, and no single one of them could ever have absorbed the rest.

As the number of staff sending images grew into the hundreds and deliveries reached customers worldwide, arranging each transfer by hand stopped scaling. EXFO needed one platform that spoke whatever interface the recipient already had: a web link for a customer with nothing to install, SFTP for a partner’s system, and a path for engineering exchange. It had to move 30 GB images reliably over long distances, take its internal accounts from the corporate directory instead of maintaining separate user lists, and keep one record of everything that moved.

EXFO selected Files.com to be that single delivery layer.

One Platform, With the Interface Chosen Per Recipient

EXFO consolidated customer delivery, partner exchange, and internal engineering transfers onto a single Files.com platform, where the interface was chosen per recipient. The tool would no longer decide who could receive a file.

Customer delivery was set up through Files.com Share Links. A support or development engineer could send a link for the customer to open in a browser, with no account to create and nothing to install. The same path could carry an ISO up to 30 GB. When files needed to come back the other way, Files.com Inboxes collected them into folders EXFO controlled.

External vendors and partners connected over SFTP, with accounts on the same platform, using the clients their systems already ran. Development teams moved ISOs and in-development modules between engineering sites through Files.com, so internal exchange followed the same rules as external delivery.

Identity came from the directory. Internal users across development and IT support were provisioned through Files.com’s Azure AD integration alongside EXFO’s legacy on-premises Active Directory, so accounts followed the directory instead of being created and retired by hand in each tool. Because every protocol ran on one platform, Share Link downloads, SFTP sessions, and internal transfers appeared in one audit log.

Three Tools Retired, One Delivery Operation

With Files.com in production, EXFO retired Dropbox, Egnyte, and ShareFile from the large-file workload while SharePoint and OneDrive remained in the estate for internal collaboration. Delivery work that had been spread across five products became a standing operation: support engineers could send a Share Link without per-delivery setup, hundreds of development and IT support staff worked through directory-governed accounts, and transfer activity became searchable in one audit log.

The compounding result is what the next recipient costs. A new customer, a new vendor, or a new engineering site is a choice of interface on a platform EXFO already runs, not another product added to the estate.

Software Delivery as a Standard Operation

Today, putting a 30 GB image into a customer’s hands on another continent is routine work at EXFO. A support engineer with a fix ready used to start by working out which sharing tool this particular customer could use; now they send the link and move on to the next case. What changed is the category of the problem. Distributing software to a worldwide hardware install base was never a file-sync job, and EXFO stopped forcing it into one: it is managed file transfer, and it runs on one Files.com platform that speaks whatever interface the recipient brings.