Sound familiar?

Here’s the part most quotes conveniently skip: WebTop end-of-support is a client problem, not a repository problem. Your content, metadata, audit trails, and retention policies live in the repository. On the supported upgrade path, none of it moves. This guide shows you why that matters, and what it saves you.

Your three options, compared honestly

Every path has a real cost. Here they are side by side, including the one nobody quotes you for: doing nothing.

Prefer a table? Here’s the same comparison in one grid.

Option	What it means	Cost drivers	Risk	Realistic timeline
Upgrade to D2 / SmartView The supported path	Keep your repository, content, metadata, and security model. Replace only the WebTop client with D2 (configurable, role-based UI) and/or SmartView. Usually paired with a platform upgrade to CE 23.x.	Migration services; re-working WDK customizations as D2 configuration; training; validation in regulated environments. Content itself doesn’t move, which keeps cost far below replatforming.	LOW–MODERATE Content and audit history stay in place. Main risk is underestimating WDK scope. An upfront inventory fixes it.	3–9 months, depending on customization depth and validation requirements.
Stay on WebTop past Feb 2027 Do nothing	Keep running an unsupported, deprecated client on your system of record.	Near-zero upfront. The bill arrives later: no security patches, no fixes, no vendor escalation, browser compatibility decay, and eventually an emergency migration under pressure, the most expensive kind.	HIGH, COMPOUNDING In insurance, banking, oil & gas, and public sector, “unsupported client on the system of record” is an audit finding waiting to be written.	Not a plan. A countdown. Every quarter of delay shortens the runway for a controlled migration.
Replatform to a different ECM The rip-and-replace quote	Move every object (content, metadata, versions, renditions, audit trails, business logic) to a different platform entirely.	The largest by far: migration tooling and rehearsals, metadata mapping, security redesign, integration rebuilds, full revalidation, retraining.	HIGH Content migrations are where records go missing, audit trails break, and timelines double. Justified by independent strategic reasons, not by a client deprecation.	12–24+ months for a repository of any real size in a regulated environment.

The short version: the proportionate response to a client deprecation is to modernize the client. Not to move terabytes of regulated content because a UI reached end of life.

What this means in a regulated industry

In insurance, banking, oil & gas, and public sector, the client swap touches things your auditors care about. The D2 path handles most of them by architecture. Here’s the cause-and-effect chain:

• The rule

  Regulated records must stay provable

  Audit trails, retention policies, holds, and disposition schedules live in the repository, not the client. Your auditors expect every one of them preserved and verifiable through any change.

• The risk

  Moving content is where proof breaks

  Replatforming moves the repository, and content migrations are where audit trails break and records go missing. On the D2 path the repository stays in place, so existing audit history is preserved intact. That’s the strongest argument against replatforming, where audit-trail continuity becomes a compliance question you’ll have to answer.

• The cost

  Validation is a real workstream either way

  Validated environments need the new client formally qualified: requirements traceability, IQ/OQ-style testing, documented change control. Budget it as a workstream. It’s often 20–30% of total project effort.

• Records & retention. Retention policies, holds, and disposition schedules survive the client swap, but verify them in testing anyway. “It should carry over” is not evidence.
• Security model. Many WebTop estates carry 15+ years of permission sprawl. The migration is the natural moment to rationalize it, with a documented before/after for your auditors.
• Access reviews. Schedule the first post-migration access recertification early. It doubles as validation evidence that the security model migrated correctly.

What a realistic migration looks like

A WebTop-to-D2 migration for a regulated organization runs in five phases. Total: roughly 4–9 months. Lightly customized estates land at the short end; heavily customized WDK estates with formal validation land at the long end.

1. Assessment & inventory: platform version, WDK customization inventory, integration map, user/role analysis, validation scope. Surprises are cheapest here. 2–4 weeks
2. Design: D2 configuration design (workspaces, doclists, lifecycles, taxonomies), mapping each WDK customization to D2 config or plugin, security review, validation plan. 3–6 weeks
3. Build & configure: D2 environment setup, configuration, plugin development where config can’t cover, platform upgrade to CE 23.x if in scope. 6–12 weeks
4. Test & validate: functional testing, UAT with real business scenarios, performance testing, and formal validation with documented evidence. 4–8 weeks
5. Rollout & hypercare: phased cutover by department, training, WebTop decommissioning, rapid-response hypercare window. 3–6 weeks

Work backward from February 2027: a project starting now is comfortable. A project starting in late 2026 is doing validation under deadline pressure. The assessment costs 2–4 weeks and converts the unknown into a plan.

Proof it works: a WebTop-to-D2 migration we delivered

Frequently asked questions

Does WebTop end-of-support mean my Documentum repository stops working in February 2027?

No. The repository (Content Server) and the WebTop client are separate things. February 2027 is when support ends for the WebTop client. Your repository keeps running. But the interface your users depend on becomes unsupported: no security patches, no fixes, no vendor help. For regulated content, that’s an unacceptable posture even though nothing “turns off.”

What replaces WebTop?

D2 and SmartView, the modern Documentum clients WebTop was deprecated in favor of. D2 is configuration-driven (role-based workspaces, configurable lifecycles and workflows), so much of what needed custom WDK code in WebTop becomes configuration in D2. SmartView provides the modern, simplified user experience layer.

Do my WebTop customizations carry over to D2?

No, and this is the most important scoping question in the whole project. WDK-based customizations must be re-implemented, usually as D2 configuration (the majority) or D2 plugins (the minority that configuration can’t cover). An honest customization inventory in week one is the difference between an accurate estimate and a surprise in month four.

Will we lose our audit trails or retention policies in the migration?

On the D2 upgrade path, no. Audit trails, retention policies, versions, and renditions live in the repository, which doesn’t move. This is the strongest argument for the upgrade path over replatforming in regulated industries. You should still verify all of it in formal testing; in a validated environment, “preserved by architecture” still requires documented evidence.

How long does a WebTop-to-D2 migration take?

Typically 4–9 months end to end: shorter for lightly customized estates, longer where deep WDK customization or formal validation is in scope. The assessment phase alone (2–4 weeks) gives you a reliable number for your estate. That’s why we recommend doing it early even if the migration itself is scheduled later.

Do we need to upgrade the Documentum platform at the same time?

Often, yes. And usually you should want to. If you’re not on the current CE 23.x line, bundling the platform upgrade with the client migration means one testing cycle, one validation effort, and one change window instead of two. The assessment determines whether your current version supports your target D2 release or whether the platform upgrade is mandatory.

Document platform work, delivered

Real engagements from the portfolio. Same platforms, same problems.