Designing the Consolidated Target Platform

"Just point everything at the big server." There is a way to consolidate sprawl that produces sprawl, and that sentence is how it starts. You pick a single big server, point everything at it, and grant each flow the access it asks for. You let the folder structure grow the way the old estate grew: organically, per request, per emergency. Eighteen months later you have one server doing what seventeen used to. Except now a single misconfiguration exposes every department's data to every other. Nobody can say which folder belongs to whom. The "consolidated" platform is a sprawl of its own inside one hostname. Fewer servers is not the goal. A platform you can know is the goal, and that requires design, not just migration. Sprawl does not mind living at one address.

This article designs the target: the platform your keep-and-merge flows will collapse onto. It covers four decisions that determine whether the result is genuinely consolidated or merely centralized: capacity, the multi-tenant folder taxonomy, authentication consolidation, and naming. Each is judged against one rule stated below. It is the fourth article in our Sprawl Consolidation series. Its inputs are the keep-and-merge set from triage. Its output is the platform that execution will migrate flows onto.

The Beat-the-Sprawl Test

Every design decision in this article answers to a single question, so it comes first:

The test works because sprawl was not an accident of tooling; it was an accident of design defaults. Servers multiplied because the path of least resistance was a new server. Access grew tangled because the default was "grant what is asked." A consolidated platform beats sprawl only if its defaults run the other way. The easy thing must be to add a tenant to the existing platform. The hard thing must be to stand up something new. Hold every decision below against the test, and the design comes out consolidatable rather than merely consolidated. Defaults are the only policy that enforces itself.

Decision 1: Capacity — One Platform, Sized Honestly

The first instinct after counting seventeen servers is to assume you need a large fraction of seventeen servers' worth of hardware. You almost never do. Sprawled estates are radically underutilized: each server was sized for its peak and then ran at a fraction of it. That is because a box provisioned for one department's month-end burst sits nearly idle the rest of the time. Consolidation reclaims that waste. The combined average load of many flows is far below the sum of their provisioned peaks, and their peaks rarely coincide. Most of those boxes spent their careers waiting for month-end.

Size the target from evidence, not from the old server count. The register's usage data gives you the inputs. They are concurrent sessions at busy periods, daily data volume, storage footprint per flow, and the shape of the peaks. Three capacity dimensions matter, and a modern multi-protocol server handles surprising load per host:

• Concurrency — how many sessions run at once at the busiest moment across all merged flows. Sum the register's peak-concurrency evidence; the true figure is usually well under the naive sum because peaks are staggered.
• Throughput and volume — aggregate bytes per day and the burst rate. Check that the network path to the consolidated host can carry the combined peak, since you are now concentrating traffic that used to be spread across subnets.
• Storage and retention — how much data lands and how long it stays. This is where consolidation can bite if you forget it: seventeen servers' worth of accumulated files, migrated naively, is a large disk. Apply retention deliberately, per our retention policy guidance, so the target inherits the flows without inheriting a decade of forgotten files.

On the beat-the-sprawl test, capacity has a specific trap: never let "we might run out of headroom" justify a second parallel platform. Two platforms doing the same job is the exact pattern you are eliminating. If genuine capacity or availability needs exceed one host, the answer is a designed pair. That means an active-standby or load-shared cluster presenting as one logical platform with one taxonomy and one owner. It does not mean a second independent server that will accrete its own tenants. One platform, sized honestly, possibly made resilient; never two platforms by accident.

Decision 2: The Multi-Tenant Folder Taxonomy

The folder structure is the heart of the design, because it is what makes one platform safe to share. The principle is multi-tenancy: each department, partner, or flow gets an isolated area. Each tenant sees only its own area and cannot reach another tenant's data even by accident. Consolidation without tenancy is just co-mingling, and co-mingling one server's blast radius across the whole estate is worse than the sprawl you started with.

The triage step already grouped your merges by target tenant — that grouping is the taxonomy's top level. A clean structure has three or four deliberate layers and no more, because depth is where taxonomies rot:

CONSOLIDATED PLATFORM — FOLDER TAXONOMY

/tenants/
  /engineering/            <- tenant = owning department
    /inbound/              <- direction, consistent everywhere
    /outbound/
    /archive/
  /finance/
    /inbound/
    /outbound/
  /partners/
    /acme/                 <- one area per partner
      /inbound/            <-   from partner to us
      /outbound/           <-   from us to partner
    /globex/
      /inbound/
      /outbound/

RULES
  - A tenant sees ONLY its own subtree. No cross-tenant paths.
  - Same direction words everywhere (inbound/outbound/archive).
  - Depth is capped: tenant / direction / (optional date). No deeper.
  - Every tenant has a named owner. No ownerless areas, ever.
  - New flow = new folder under an existing tenant, not a new tenant
    unless a genuinely new party appears.

Three properties make this beat sprawl. Isolation means a mistake in one tenant cannot expose another. That is the property that let you consolidate at all. It is the one a platform must enforce at the permission layer, not just by convention. A server such as Sysax Multi Server is built for exactly this shape. It hosts many tenants on one Windows service with per-account isolation and per-area permissions. So each account is confined to its own subtree by the server itself. Consistency means the same direction words appear in every tenant, so a script or a person moving between areas finds the same shape. Predictability is what keeps the taxonomy usable as it grows. Bounded depth means the tree cannot sprout the private sub-warrens that made the old estate unnavigable. A capped depth forces new work into the existing structure rather than beside it. The directory-design reasoning behind all three is developed in our designing directory trees article, applied here at the scale of the whole estate.

Decision 3: Consolidating Authentication

Sprawl is not only sprawl of servers — it is sprawl of identities. The old estate had accounts scattered across seventeen machines. There were local accounts here, a directory integration there, and shared logins nobody rotated. There were service accounts named after departed staff (the pattern our accounts outlive their owners article dissects). Consolidating the servers without consolidating the identities leaves half the problem intact, because every stray credential is still a door. The target design decides, once, how everyone authenticates. Some of those accounts have outlasted the people, the servers, and two reorganizations.

Aim for the fewest authentication sources that cover your populations, and let the platform speak to each natively:

• Internal users and jobs should authenticate against your existing directory — Windows or Active Directory. That way, joiners, movers, and leavers are handled by the identity processes you already run. A departure removes transfer access automatically. A platform that can authenticate against Windows and Active Directory as well as its own built-in accounts lets you put internal populations on the directory. It also lets you reserve built-in accounts for the cases that genuinely need them.
• Partners and external parties usually cannot live in your directory, so they get built-in platform accounts — but designed, not accreted. That means one account per party, scoped to that party's tenant area, with a defined credential lifecycle. The partner-credential discipline is the subject of our partner credential lifecycle article. The target is where you finally get to apply it uniformly instead of per-server.
• Network-level scoping backs the credentials. IP allow and block rules restrict where each account can connect from, so a partner account is usable only from the partner's addresses. This turns a leaked credential from a breach into a non-event. A platform with per-account IP allow/block makes it a setting rather than a firewall project.

The beat-the-sprawl test for authentication is sharp. Every account on the target must trace to a person or a party who owns it, and to a lifecycle that ends it. The estate you are retiring is full of credentials that failed that test. Examples are the shared login, the service account of someone long gone, and the partner password set once and never changed. If the new platform admits even one such account "to save time," you have seeded the next sprawl. Consolidate identities as ruthlessly as servers.

Decision 4: Naming That Survives

Naming seems trivial until you realize that the old estate's unnavigability was largely a naming failure. Hosts were called server5 and ftp-new-new (there was, at some point, an ftp-new). Accounts named neither their owner nor their purpose. Folders had meanings that lived only in the head of whoever made them. A consolidated platform gets one chance to set conventions that will still make sense to a stranger years from now. Decide them up front and write them down:

NAMING CONVENTIONS — decide once, apply everywhere

Host / platform:  role-based, not sequential
                  transfer-prod-01, not server5
Tenant folders:   the owning party, lowercase, stable
                  engineering, finance, partner-acme
Accounts:         purpose-or-party + type, never a person's initials
                  svc-finance-nightly, partner-acme, jdoe (interactive)
Service accounts: svc- prefix + owning team + function
                  svc-eng-buildpush   (owner is the TEAM, not a human)
Dated files:      fixed sortable token, one format estate-wide
                  statements_YYYYMMDD.csv   (never locale date strings)

RULE: a name should tell a stranger WHOSE it is and WHAT it does,
      with zero tribal knowledge required.

Two conventions do outsized work. Service accounts named for the owning team, not a person, kill the single most common ghost-account pattern. That is the job still running as an employee who left years ago. And dated filenames in one fixed sortable format across the estate matter. The reasoning is in our naming convention design article. These filenames mean scripts on the new platform can parse and sort files predictably regardless of which old server they came from. Naming is cheap to get right at design time and expensive to fix once forty flows have baked in the wrong conventions. I have renamed a live service account once. Once was educational.

The Automation Side of the Target

The target is two things, not one. The server platform hosts the flows others push to and pull from — that is decisions one through four above. But your triage also produced a pile of scripts to keep: the scheduled jobs, watch-folder tasks, and batch files that initiate transfers. Scattering those across personal task schedulers and workstations is how the automation half of the sprawl grew in the first place. So the target design includes a consolidated home for the jobs too.

The principle mirrors the server side. The jobs you keep move onto one scheduling platform with central logging, credential storage, retry, and error handling. Those are properties homegrown scripts on scattered machines rarely have. A tool built for this, such as Sysax FTP Automation, runs wizard-defined tasks on a schedule or on folder-arrival triggers, with notifications and retry. So the jobs become inspectable and owned rather than hidden in a dozen crontabs. The design decision here is the same beat-the-sprawl question. A new job should be a task on the existing scheduler, not a new script on whatever machine is handy. Get that default right and the automation estate stays as consolidated as the server estate.

Where the Platform Lives

One architectural question sits above the four decisions: where does the consolidated platform sit relative to your network boundary? This is genuinely a design choice rather than a default. It interacts with which flows are inbound from partners, which reach out, and how much you are willing to expose. The patterns are the subject of their own body of work. They include a hardened endpoint in a DMZ, a gateway that keeps data out of the DMZ entirely, or an internal platform reached only through a proxy. Rather than duplicate that work, the placement decision draws on the gateway and proxy architecture patterns in our transfer gateways and proxies pillar. For the purposes of this design, record the placement as a constraint on the target. It determines the network paths the migration must open and the exposure the risk ranking must account for.

Testing the Design Before You Build It

Before a single flow migrates, run the design against the estate on paper; paper is the cheapest test environment you will ever have. The check is mechanical and it catches expensive mistakes while they are still cheap to fix:

TARGET DESIGN CHECK — run before building

[ ] Every keep/merge flow maps to exactly one tenant area
[ ] No flow needs cross-tenant access to work (if one does,
    the taxonomy is wrong — fix it now, not in production)
[ ] Concurrency + volume + storage sized from register evidence,
    with headroom, on ONE platform (or one designed cluster)
[ ] Every internal population authenticates via the directory
[ ] Every partner has one scoped account + IP allow rules
[ ] No shared logins, no person-named service accounts survive
[ ] Every tenant area has a named owner
[ ] Names pass the stranger test: whose is it, what does it do
[ ] Kept scripts have a consolidated scheduler home
[ ] Platform placement (DMZ / gateway / internal) is decided
[ ] Activity logging is on and lands somewhere central

The most valuable line is the second: no flow needs cross-tenant access. If a flow genuinely requires reaching into two tenants' areas, your tenant boundaries are drawn wrong. Finding that on paper costs an afternoon while finding it in production costs a re-migration. Walk every merged flow through the taxonomy mentally and confirm it lives entirely within one tenant's subtree. The last line matters nearly as much: activity logging that lands in one central place. It makes the next review — and the re-sprawl prevention this program ends with — a query instead of another discovery sweep. The periodic access review you will run on the consolidated platform depends entirely on the logging you decide to turn on now.

Bluewater Bank found the second line's value on paper. Their design check walked a reconciliation job through the taxonomy. The job read from the Acme partner's inbound area and wrote to Finance's outbound area in one step. That is exactly the cross-tenant reach the rules forbid. Rather than grant the exception, they split the job. The partner tenant's landing folder handed files to a Finance-owned pickup task on the scheduler. Each half stayed inside one subtree. The redraw took an afternoon and a whiteboard. Had the exception been granted, it would have been the first cross-tenant path on the new platform. In my experience the first one is never the last.

From Design to Execution

A finished target design is a specification. It includes a sized platform, a tenant taxonomy with owners, an authentication model, and naming conventions. It also includes a scheduler for the kept jobs and a placement decision. All are tested against the estate on paper before anything is built. That specification is what turns the risk-ranked verdict list from triage into a concrete migration. Each merge now has a destination folder, an account model, and a name waiting for it.

What remains is to move the flows without breaking them — in waves, with parallel runs and grace periods. You also need proof that each retired endpoint is truly empty before it goes dark. That is the craft of executing consolidation without breakage, and it is where a good design meets the messy reality of live flows that cannot stop. You may even point everything at the big server now. It has a design.

Frequently Asked Questions