A Legal-Tech Software Company Replaces AWS Transfer Family With One Governed Files.com Layer for Client Intake and Document Work

A legal-tech software company makes corporate-records software for legal, corporate-secretarial, and compliance teams that keep business records transaction-, audit-, and compliance-ready. Its clientele holds some of the most confidential records a business produces and treats a leaked or missing document accordingly.

That business model creates a file problem before a single line of the product is used. The company wins customers by migrating them off legacy records systems, so every new customer begins by handing over its corporate records: spreadsheets, Word documents, and large volumes of PDFs of legal filings. The company's implementation team sorts those files, works on them, and keys their contents into the product by hand. A typical project brings hundreds of documents. A large one can run to thousands, arriving in weekly drops over two to three months. And the company is a distributed, remote-first business, which meant a business built on hands-on work with other people's confidential files needed a governed place to do that work.

Object Storage Is Not a Working File System

The company's working file layer had once been an on-premise NAS in an office. As a remote-first company, it needed that layer in the cloud.

The interim answer was AWS. Amazon S3 with AWS Transfer Family gave clients an SFTP endpoint to drop records into, and FSx handled internal sharing. It covered secure storage and secure transfer. It did not cover the work. S3 is object storage, not a file system, so even renaming a folder was slow, and editing in place was impossible.

The company wanted the implementation team to open, rename, sort, and edit client records in place, on a platform that logs every action, with no download-and-re-upload step in the process.

Intake From a Browser as Well as SFTP

Intake had a requirement of its own. It ran over SFTP only, and the company wanted a browser upload that a paralegal or corporate secretary could use without involving their own IT department, with SFTP kept for the clients who prefer it, so every confidential record arrives on one governed path.

The project load set the scale. The company was running as many as 50 customer projects at a time, roughly 20 of them active at once, with weekly inbound drops on each. The intake and working layer had to carry that volume without a manual step per document.

What the fix had to do was clear before any product was named: keep each client's records segregated from every other client's; give non-technical clients a browser upload while keeping SFTP for those who wanted it; let the implementation team work on files in place on the platform; pin each client's data to the country it must stay in, Canadian client data in Canada and US client data in the US; and log every action. The company selected Files.com to be that governed file layer.

One Governed Layer Between the Client and the Product

Files.com became the single file layer between the company's clients and its own product: the intake surface where records arrive and the working surface where they are prepared, running as a branded portal on the company's own domain with staff signing in through Google SSO.

On the intake side, every client got its own segregated folder. Longer projects get the client created as a Files.com user with access to that folder and nothing else. Shorter ones get a share link instead. Non-technical clients upload through the web page, and clients who prefer SFTP still connect that way, into the same folder under the same controls.

On the working side, the Files.com Desktop App gave the implementation team what the NAS used to provide: native Finder and Explorer access, renaming, sorting, drag-and-drop between systems, and unzipping archives in place, all executed against the platform.

Governance sits underneath both. Each client's folder is pinned to the region its data must stay in, so residency is decided by where the folder lives. The regionally separated S3 buckets stayed in the picture, but behind the platform, connected through Files.com remote server mounts as back-end repository and backup rather than as the surface anyone works on. Audit logs record every action, and client source records are retained for a set period and then deleted. The company completed the cutover in phases, first moving the professional-services team onto real customer data and then retiring the old SFTP endpoint.

One Governed Path From Client Upload to Product Entry

With Files.com in production, the company replaced an SFTP drop point over object storage with a single governed path from client upload to product entry.

• Confidential client records are edited, renamed, and sorted on the platform, where every action is logged. The implementation team works on each file where it landed.
• Clients upload through a branded web page without involving their own IT department, and clients who prefer SFTP connect the same way into the same folder.
• Data residency holds per client, automatically. A Canadian client's records stay in Canada and a US client's stay in the US, enforced by the folder itself.
• Onboarding the next client is a repeatable pattern: a folder, a user or a share link, and a region.

Securing the Work as Well as the Transfer

The AWS endpoint the company ran before covered encrypted transfer into encrypted storage. Files.com governs the working layer as well. Today an implementation specialist opens a client's records where they landed, prepares them where they sit, and keys them into the company's product, and the files stay on a platform that logs every action and keeps each client's data in its required country. Securing the drop point and securing the work are two different jobs, and Files.com does both.