TeamSite’s vocabulary describes how teams prepare, combine, preserve and publish website content. Understanding those boundaries helps a maintainer inspect an inherited Interwoven implementation and plan a change without losing the content records or rules behind its pages.
Read the architecture in its version context
Interwoven’s 2003 TeamSite coverage emphasized parallel development and content versioning. For a concrete documented model, the OpenText Web Content Management Architecture Guide, release 16.4 (May 2018, PDF) describes the following constructs. The document is authored by OpenText and hosted on a Canadian government site.
| Construct | Meaning |
|---|---|
| Branch | Organizes a hierarchy of site assets and its workareas, staging area and editions. |
| Workarea | An editing sandbox in which users prepare and test changes, isolated from other workareas. |
| Staging area | The branch’s shared submitted content. Submission creates a version of the submitted item. |
| Edition | A read-only snapshot of content assets for a particular branch. |
| Deployment | A publishing step that transfers content to a runtime environment; the guide describes OpenDeploy for this role. |
These terms explain the documented model, while the installed release and local customization determine operational behavior. As checked October 4, 2026, OpenText’s developer catalog uses the Web CMS name for the current offering. Product lineage alone does not identify an inherited installation’s support status or available migration tools.
Follow two edits through a release
Fictional branch: public service website
Editor A revises opening hours in one workarea. Editor B revises a contact page in another. Each previews the relevant pages, then submits through the configured review process. The release owner checks the combined staging content before selecting the approved release for deployment.
- Workarea A: opening-hours edit and preview.
- Workarea B: contact-page edit and preview.
- Shared staging: review the submitted combination and resolve overlapping changes.
- Edition: preserve a named snapshot for the branch.
- Deployment: transfer the selected release and verify the live result.
If both editors change the same navigation file, the release needs an explicit conflict decision and a combined preview. If deployment then fails, inspect the destination and deployment evidence before calling the website updated. A staged or preserved version and a live release are separate observations.
Inventory more than the rendered pages
Begin with a read-only inventory and a recoverable backup. Record the exact software release, stores, branches, workareas, editions, repository owners and important publication destinations. Then trace one representative page from its source record to its live response.
| Component | Questions to resolve before change |
|---|---|
| Content records | Which structured records, fields, versions, attachments and metadata produce the pages? |
| Templates and presentation | Which data-capture definitions, rendering templates and shared components interpret those records? |
| Assets and links | Which images, documents, relative paths and external references must remain connected? |
| Workflow | Which approvals, scripts, service accounts and external tasks affect a release? |
| Deployment configuration | Which destinations, filters, transformations and rollback assumptions are in use? |
| Integrations and access | Which external repositories, search services, identities and permissions does the site rely on? |
Use the TeamSite estate and extraction worksheet (plain text) to link each component to an owner, evidence location and intended treatment. Store credentials separately and record only protected references in the inventory.
Test extraction with a bounded collection
- Select a small branch or content type containing ordinary pages, shared assets and known exceptions.
- Record source IDs, paths, versions, metadata, relationships and the expected rendered outputs.
- Use export or extraction methods supported for the installed version. Preserve the source package before transforming it.
- Reconcile counts and identity mappings, then inspect representative fields, links, images and generated pages.
- Test access rules and the next editing workflow in the destination. Record any history, workflow or rendering behavior that needs separate preservation.
A static copy can preserve visible pages while leaving authoring structures behind. Choose it deliberately when public presentation is the preservation target. A continuing editorial service also needs a workable content model, approvals and a publication process. Plan the treatment of each dependency before committing to a full transition.