Bluecore Moved alby’s Live SFTP Endpoint off AWS on the Way to Google Cloud

Bluecore is a retail marketing platform built for 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.

Bluecore’s autumn 2024 acquisition of alby, an AI shopping assistant that works from a retailer’s catalog, brought a product, a customer base and an SFTP endpoint wired directly into Amazon S3. Bluecore was in the middle of a lift-and-shift from AWS to Google Cloud, but alby’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.

“Our customers are dropping and retrieving files to and from us, mostly pushing files to us for catalog imports, for customer imports, for eligibility updates, and any kind of data sync they need to do between their own internal tools, CRM, data lakes, and Bluecore. About 90% of that goes through file transfer.”

The Acquisition Came with an Endpoint in the Wrong Cloud

alby’s retail customers fed it the same way Bluecore’s 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 alby’s ingest, and every customer connected to it, to the cloud Bluecore was leaving.

The client side of that connection belonged to the customers, not to Bluecore. Each retailer’s upload scripts, schedules and allowlists pointed at the AWS address, and Bluecore 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 Bluecore’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. Bluecore selected Files.com, the platform already running its customer file exchange, to be that front door.

One Endpoint in Front, Two Clouds Behind

Bluecore set up a dedicated Files.com child site for alby, giving the acquired product its own users and configuration without touching the exchange Bluecore’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 Bluecore ultimately wanted.

In May 2025, alby’s customers were 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 on a five-minute cadence. 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 alby’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 Bluecore Had to Notice

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

• alby’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.

Nadia Kunkov, the Engineering Manager who owns alby’s catalog ingest, gave the path her customers landed on a three-word review:

“It just works.”

Where Customers Connect Is No Longer Where the Data Lives

Once an alby retailer’s upload script pointed to Files.com, what sat behind that address became Bluecore’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 alby’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.