ValueLabs Moves 5 GB Files at Cloud Speed With Its Hyderabad Server as the Storage Tier

ValueLabs is a Hyderabad-headquartered product development and IT consulting firm with several thousand employees and roughly 300 clients. It delivers software engineering and managed IT services to enterprise clients around the world, including financial-services accounts.

That work runs on file exchange. Working files, routinely 5 GB apiece, move between ValueLabs teams and enterprise clients around the world. The company also holds a firm rule about where its data lives: production files belong on ValueLabs-owned storage, on the company's own server in Hyderabad. Those two facts were always going to collide: a global business that moves large files every day, and one fixed place every file has to end up.

Every Transfer Had to Cross the WAN Into Hyderabad

For years, file exchange ran on internal infrastructure: on-premises file and SFTP servers fronting the Hyderabad storage. Because every file had to end up on that server, every transfer had to travel to it, no matter where in the world it started. ValueLabs had outgrown an architecture in which the location of the data set the speed of every transfer.

The cost landed on people. Against a routine working size of 5 GB per file, a normal handoff became a long wait. An employee pushing a deliverable, or a client team on another continent waiting to receive one, sat behind the same slow link into the same data center. And access to all of it was administered by hand, one account at a time, for a workforce of thousands.

The Measurement That Settled the Architecture

The obvious answers pulled in opposite directions. Keep everything on-premises and the data stays home, but every user inherits the slow path into Hyderabad. Move to a cloud platform and transfers get fast, but the data leaves ValueLabs-owned storage, which the company's own rule put out of bounds.

ValueLabs did not have to guess which constraint was real. In early 2023, the team ran an on-premises, agent-based deployment fronting its own server and measured what users experienced. A file uploaded straight to cloud storage transferred quickly. The same transfer, routed into the on-premises server, crawled.

“While uploading the files to our server it is taking a very long time, but while uploading to your platform the data transfer is fast.”

That settled the design question. The bottleneck was not the tooling. It was any architecture that put the data center in the user's path. When ValueLabs returned to the project in 2024, the requirements were specific: delivery had to be cloud-first, while the architecture had to remain hybrid. Users needed to transfer files directly through the cloud from wherever they worked, while every production file still landed on ValueLabs' own storage. Sign-in also had to run through Azure AD, using the company's existing identities. ValueLabs selected Files.com to provide that cloud front door, with its own server staying as the storage tier underneath.

A Cloud Front Door With Its Own Server as the Storage Tier

ValueLabs Corporate IT built the deployment itself, consulting Files.com support along the way. The Files.com Agent went onto the company's on-premises Linux server, where it runs as a system service that starts automatically on reboot and connects outbound, so no inbound firewall port opens into the data center. Through the Agent, the Hyderabad server is attached to the Files.com site as its storage tier.

The transfer path is what changed. Staff and external counterparties upload directly to Files.com cloud storage, and sync pushes each file down to the on-premises server within minutes of arrival. Users get the fast path without waiting for their uploads to cross the WAN into Hyderabad. Production data rests on the server the company's requirement specifies.

The whole portal runs under ValueLabs' own domain with the company's own SSL certificate, so what a client sees when exchanging files with the team is ValueLabs' own brand. SFTP and the Files.com API sit on the same site, so automated workloads travel the same path as people do.

Accounts Provisioned From Azure AD, Not by Hand

Identity came from the directory. ValueLabs connected Azure AD over SAML for single sign-on and turned on SCIM provisioning, so accounts are created, updated, and deactivated from the directory rather than by an administrator. Group sync carries Azure AD groups into Files.com, and those groups drive folder-level permissions.

For a workforce of thousands, that ends per-user account administration: a new joiner gets file access with a directory account, permissions follow group membership instead of a list somebody maintains, and a departure removes access when the directory says so.

One Front Door for the Next Workload

With the hybrid design in production by mid-2024, ValueLabs had replaced a WAN-bound transfer path and hand-managed access with a single governed portal under its own name. Employees and clients now upload directly through Files.com instead of waiting on the link into Hyderabad, production files sync to ValueLabs-owned storage within minutes, and Azure AD provisions access for thousands of employees.

The compounding result showed up later in 2024. ValueLabs runs an email gateway application whose backup had previously landed automatically on a dedicated internal SFTP server. When the team wanted that traffic on the same platform, it pointed the backup at Files.com instead, and the dedicated internal SFTP server came out of the job. That is what the front door is now for: the next file workload gets a folder on the platform the company already governs, instead of a server of its own.

The Trade-Off That Stopped Being One

Today, a ValueLabs employee uploads a 5 GB working file and gets on with the day. Minutes later, the file is sitting on the company's own server in Hyderabad, exactly where production data belongs, and the employee never touched the slow path that used to define the job. What used to happen instead was the wait: the same file moving through the data center path before work could continue.

ValueLabs did not choose between keeping its data and giving its people cloud performance. It separated where files rest from how files move. Files.com handles the movement, under ValueLabs' name and gated by ValueLabs' directory, and the company's own server keeps the data. A residency requirement still decides where every file lives. It just stopped deciding how fast anyone can work.