Replacing a legacy VPN file portal: keep the controls

The old clientless portal had a delete button, a favourite star, and a share path pasted into an email. Only one of those is a control. Replacing the portal means deciding which operations remote users still need and where each one is enforced, not reproducing the layout of a page that happened to work. Two replacement shapes cover most cases, and they fail at different points.

A button is not a permission

Start with the operation list: read, upload, rename, delete. Decide which roles get each one, then enforce that decision at the file service rather than in the interface. Hiding a delete control in a new portal leaves the backend permission intact, and anyone with a native client and the same account can still remove the file.

Deletion deserves a separate decision because it is the operation users regret. Ask where a deleted item can actually be recovered from, and do not assume the answer is the laptop's recycle bin or the portal's own trash. A network share generally does not route deletions through the local recycle bin.

On a Windows-backed share, Volume Shadow Copy provides the snapshot machinery and the coordination that backup software uses, but its presence says nothing about whether this share retains versions you can restore. The file-service owner has to confirm the version policy and demonstrate a restore before the portal is retired.

Option A: a native file client over the tunnel

A mapped drive or an SMB client keeps the operations users already know, and permissions are enforced by the file server on every request. The identity that matters is the file-service identity, so access survives a change of VPN product as long as the tunnel still carries the traffic and the account still exists.

The cost is that the client must reach the service directly. Name resolution, port reachability, and the authentication method all become part of the remote-access design, and a portal that used to proxy the connection hid every one of those requirements. Users on unmanaged devices also get a share mounted in their file manager, which is a wider surface than a browser tab. Budget for that support load before the migration, because it arrives on the first day rather than after a grace period.

Recovery is the strongest argument for this shape: previous versions and restore permissions are native to the platform, and the help desk can use the same procedure it uses on site.

Option B: a proxy or application gateway

A portal that fetches the file and streams it to the browser keeps the file service off the user's network path. That is useful when the device cannot join the tunnel or when the organisation wants every request logged at one choke point. The trade-off is that the proxy becomes a participant in every operation, and it must carry the user's identity through to the file service instead of using its own service account for everything.

Delete and rename behaviour has to be implemented rather than inherited. If the proxy exposes a delete action, that action calls the backend with some identity, and the audit trail should name the user rather than the gateway. If the proxy cannot rename, say so before users discover it halfway through a project.

Link rewriting is where this shape quietly changes meaning. A URL that the portal proxies is not the same object as a URL the browser opens directly, and converting one into the other can strip the authentication context that made it work.

Names, identities, and the links in between

Distribute the approved server and share path, not a domain browsing list. Browsing depends on discovery services that may not cross the tunnel, and a path that works because the user's laptop can enumerate a domain is a path that breaks on the next unmanaged device.

Review single sign-on application by application. A token issued for the portal should not be replayed to a file service that never validated it, and query parameters that carry identifiers should not be copied into a public link just because they appeared in the old bookmark. Treat each approved application as its own trust boundary.

Choose against the requirement list

Neither shape wins outright. A workforce on managed laptops with a working tunnel gets more from the native client, because restore and permissions come from the platform rather than from a reimplementation. A mixed population of contractors and personal devices may justify the proxy, provided the identity plumbing is real and not a shared service account.

Write the comparison down against the four operations and the recovery answer, then retire the old portal only after one restore has been performed through the new path. That test exercises the parts of the design that a successful login never touches.