The Baldwin Group Replaces Custom AWS Builds With Files.com S3-to-SharePoint Automation

The Baldwin Group is an independent insurance distribution firm delivering insurance, risk management, employee benefits, and Medicare and ACA solutions to more than two million clients across all 50 states. It ranks eighth among the largest property and casualty insurance agencies in the United States, and behind the advisory business sit insurance-processing divisions that run on documents moving between systems every day.

Baldwin's technical estate splits those documents across two worlds. The data behind its insurance-processing work lives in AWS S3, an environment only engineers can safely touch. Its business staff do their daily work in SharePoint. For years, the distance between the two was covered one of two ways: by hand, or by a custom implementation built in AWS.

Every Automation Was a Custom AWS Build

Whenever the business wanted a manual process automated, including simply getting documents out of S3 and into the hands of the people who needed them, the platform team had one option. Design a bespoke implementation in AWS, build it, and maintain it. Each automation was a development project with a queue behind it.

The cost landed on the business. Manual steps consumed staff time across both insurance-processing divisions. Employees either waited on the technical team or could not reach documents at all, because the one shortcut available, handing business users AWS access, was never an acceptable answer. The engineers did not want non-technical staff anywhere near the AWS console, and the staff had no reason to learn it. SharePoint was already where they worked.

The pattern survived because it worked, one build at a time. The AWS implementations were sound. The model was the problem: bridging object storage and SharePoint with custom code per workflow meant the backlog of manual processes could shrink only as fast as engineering capacity allowed, and as workflows accumulated across divisions, that stopped being fast enough. Baldwin had outgrown building automation one project at a time.

A Standing Layer Between S3 and SharePoint

What the team needed was not another build. It was a standing layer that could read Baldwin's S3 buckets directly, deliver documents into the SharePoint sites staff already use, run on a schedule with nobody touching it, and extend to the next workflow or division without new development, all while keeping AWS credentials in engineering hands only.

Baldwin's platform engineering and cloud teams made Files.com that layer, adopting Files.com Automations as the standard replacement for one-off AWS builds.

Using Files.com Remote Server Mounts, the team connected the S3 buckets to the platform. The documents stay in Baldwin's own AWS account, and Files.com authenticates to the buckets itself through AWS STS role assumption, so no credentials are ever handed out with the data. On the delivery side, scheduled Files.com syncs move documents from those buckets into SharePoint. Business users never see the platform at all. The document simply appears where they already work.

The connections were built up incrementally, and when the automation programme expanded from one insurance-processing division into the second, the team reused the existing configuration rather than starting a new build. That reuse is the design working as intended: the layer was built once, and every workflow after the first rides on it.

Automation Became Configuration

With the Files.com workflows in production, Baldwin replaced a model in which every automation opened a development project with one in which automation is configuration on a platform already running.

The compounding result is the larger one. When the team finds a manual process now, the question is what it costs in time and whether a Files.com automation removes it, not whether an engineering build can be scheduled. The marginal cost of the next automation collapsed, and that is what turned a backlog into a working programme.

A Different Answer to the Next Manual Process

Before, a document sitting in an S3 bucket was, for most of Baldwin's staff, out of reach. Getting it meant asking an engineer, and automating the ask meant waiting on a custom build. Today an employee in an insurance-processing division opens SharePoint and the document is there, delivered by a Files.com sync from a bucket that person will never need to see.

What Baldwin's teams established is that manual file workflows do not each need their own cloud development project. With Files.com as the standing layer between the object storage engineers run and the tools staff already use, automating the next process is configuration, not code.