A Retail Marketing Platform Moved an Acquired Product’s Live SFTP Endpoint off AWS on the Way to Google Cloud

A retail marketing platform serves enterprise retail brands. Its predictive intelligence connects shoppers to products, content and offers across email, site, paid media, social and SMS. All of that personalization runs on data retailers send: product catalogs, customer records and eligibility updates. Nearly all of it arrives as files.

An acquisition brought the company a product, a customer base and an SFTP endpoint wired directly into Amazon S3. The company was in the middle of a lift-and-shift from AWS to Google Cloud, but the acquired product’s customers controlled the upload scripts, schedules and allowlists pointed at that inherited endpoint. Moving the storage risked forcing every customer integration to move with it.

The Acquisition Came with an Endpoint in the Wrong Cloud

The acquired product’s retail customers fed it the same way the company’s own did: they pushed catalog files over SFTP. The endpoint they pushed to was an AWS service wired straight into an Amazon S3 bucket, and that wiring was the problem. The inherited endpoint tied the product’s ingest, and every customer connected to it, to the cloud the company was leaving.

The client side of that connection belonged to the customers, not to the company. Each retailer’s upload scripts, schedules and allowlists pointed at the AWS address, and the company could not change any of them. That left three options, none of them good. A straight swap to a new endpoint risked breaking every customer’s upload workflow at once. A coordinated cutover meant asking every retail customer to change and re-test its integration on the company’s timetable, in the first months after an acquisition, exactly when those customers most want to hear that nothing is changing. And doing neither meant running AWS indefinitely and never consolidating the acquisition at all.

What the migration needed was an endpoint customers could be pointed at once and never again: a front door decoupled from the storage behind it, able to keep the old S3 path and the new Google Cloud path consistent while both had live users. The company selected Files.com, the platform already running its customer file exchange, to be that front door.

One Endpoint in Front, Two Clouds Behind

The company set up a dedicated Files.com child site, giving the acquired product its own users and configuration without touching the exchange the company’s existing customers depended on. The team then used Files.com Remote Server Mounts to attach a Google Cloud Storage bucket as a remote folder, wiring in the destination the company ultimately wanted.

The acquired product’s customers were then repointed to Files.com as the front door for uploads. Behind it, a two-way Files.com sync kept the site’s folder tree and the existing S3 bucket matched. That mattered because both endpoints stayed live on purpose: some customers had moved to Files.com while others still pushed to the old AWS address, and both sides had to see the same files. Nobody was forced onto a deadline, and the rollover was staged deliberately so that the product’s customers felt nothing.

The next stage was designed to flip the direction of travel. A one-way sync from the same folder tree into the mounted Google Cloud bucket would make GCP the destination of record and allow the AWS side to retire. That stage remained planned, with AWS still supporting the transition. When it occurred, no customer would need to change anything because customers were no longer connected directly to the storage. They connected to Files.com.

A Cloud Migration Nobody Outside the Company Had to Notice

With Files.com in front of the ingest path, the company replaced a customer-coordination problem with an internal storage decision.

• The acquired product’s retail customers repointed once, to Files.com. Future storage changes behind that address no longer required a customer to touch a script, credential or allowlist.
• There was no synchronized cutover to plan or survive. Customers moved at their own pace while the two-way sync kept the old endpoint and the new one consistent, and ingest ran uninterrupted through the transition.
• Absorbing partner-facing infrastructure became a repeatable pattern on the platform: a child site for the acquired product, a mounted bucket for wherever its data belonged and one repoint for its customers.

Where Customers Connect Is No Longer Where the Data Lives

Once a retailer’s upload script pointed to Files.com, what sat behind that address became the company’s decision alone. Before Files.com sat in front, those were one decision: an SFTP endpoint wired straight into an S3 bucket meant that moving the storage meant moving every customer with it. The migration never needed the acquired product’s customers to move. It needed the endpoint to stop belonging to a cloud, and once Files.com became that endpoint, an acquired product’s ingest path stopped being a reason a cloud migration waits.