School of Visual Arts Replaces AWS Transfer With Files.com So Staff Can Publish to Canvas From Existing S3 Storage

The School of Visual Arts is a private art and design college in Manhattan, offering undergraduate and graduate programs across the visual and applied arts.

Course delivery runs through Canvas, the college’s learning platform. The content behind those courses lives in an Amazon S3 bucket in SVA’s own AWS account, and Canvas serves from that bucket. But the people who create and maintain course content needed a practical, governed place to work with it. SVA replaced AWS Transfer with Files.com, giving content owners a folder for publishing directly into the existing bucket without migrating the data.

SVA Needed More Than Protocol Access

Amazon S3 is a good home for content a platform reads at scale. It is a poor workplace for a person. SVA had bridged that gap with AWS Transfer, which put a protocol endpoint in front of the storage.

But SVA needed more than a protocol endpoint. It needed to admit staff under the identity SVA already managed in Okta, scope each person to the course-content area and nothing else, and land every upload directly in the bucket Canvas reads.

Because that bucket was what Canvas served from, SVA chose to keep the content in its existing S3 bucket and fix how staff accessed it. SVA selected Files.com to be that front door.

A Governed Front Door on a Bucket That Never Moved

Using Files.com Remote Server Mounts, SVA connected its S3 bucket to its Files.com site. The folder in Files.com presented the bucket itself, so nothing was copied and nothing migrated, and the content stayed in SVA’s own AWS account. As part of the cutover, the top of the bucket was reorganized to give course content a dedicated folder, and content owners were directed to publish through it.

Access control was placed in front of the mount rather than inside AWS. Staff signed in through Okta using Files.com single sign-on, and folder-level permissions scoped each upload user to the course-content folder. The web interface gave staff a place to work directly, while SFTP remained available for client-based access. A file uploaded into the folder landed in the bucket where Canvas reads it.

Publishing Course Content Became Staff Work, Not Engineering Work

With the mount in production, Files.com replaced AWS Transfer with a workspace the content team could use directly. Content owners now publish and update course content through Files.com, with each upload landing in the bucket Canvas serves from.

AWS Transfer was retired while the content remained in SVA’s AWS account. Giving the next staff member publishing access is now a folder permission granted to an existing Okta identity.

Fixing the Access Instead of Moving the Data

The person who owns the content can now make the change, signed in with the account they already use, in a folder scoped to exactly that work. Canvas serves the result from the same bucket it always has, and SVA never ran a migration to get there.

The storage that non-technical staff could not use did not need to move. It needed Files.com standing in front of it.