# Plan a Content Central test environment

Decide whether you need a full test copy, know the four things a real copy requires — and use the worksheet that keeps a test server from emailing customers or pushing real data.

Product: content-central · Versions: 7.x · Audience: system-administrator · Time: 10 minute read · Last verified: 2026-08-30

Canonical: https://help.ademero.com/content-central/administration/plan-a-test-environment

**At the end of this page you'll have a filled-in worksheet — what you're testing, what the copy needs, and how it will be isolated — which is what has to exist before anyone builds anything.**

"Create us a test environment" usually arrives with no requirements attached, and the build is the easy part. The planning is the deliverable, because a copy of production is not a passive thing: Content Central actively sends email, runs scheduled workflows, exports data, talks to accounting systems, and pulls documents out of folders and mailboxes. A copy that starts with production settings does all of that **for real**.

## Start with what you're testing

Not every test needs a second server:

| You want to test | You probably need |
| --- | --- |
| A new workflow, document type, or capture design | A **test catalog inside production** |
| An upgrade rehearsal | A full isolated copy |
| An integration (QuickBooks, Sage, ERP) | A full isolated copy |
| SSO changes, a server move, or anything risky | A full isolated copy |

A "test catalog" is a technique, not a product feature: catalogs are ordinary containers an administrator can create, each with its own storage path. Since new workflow rules are disabled by default and rules can be scoped to one catalog, a `TEST` catalog keeps the blast radius small — with no second server, license, or refresh plan to maintain.

The full copy earns its keep for upgrades: Content Central upgrades the database schema the first time new binaries start, and older binaries then refuse to run against the upgraded database. That is exactly the kind of one-way door you rehearse on an isolated copy, never on production.

> **NOTE:** A partner demo environment is planned with this same worksheet — the licensing question below just matters even more.

## What a real copy is made of

Content Central runs as six Windows processes — the IIS web application plus five Windows Services — all sharing one SQL Server database, one connection file, and the same document storage folders. A real copy therefore needs all four of these:

1. **The database** — a verified backup, restored to the test SQL Server. See [Back up your Content Central database](/content-central/administration/back-up-your-content-central-database).

2. **The document storage folders** — documents are files on disk, not rows in the database. A database copy alone is incomplete. Copy the database and the storage folders in the same window.

3. **A Content Central install on the test server** — with its own licensing story (below).

4. **A repointed connection file** — `%ProgramData%\Ademero\Content Central\ConnectionInfo.xml` on the test server must point at the **test** database, never at production.

> **IMPORTANT:** On the test server, keep the Content Central services **stopped** until the isolation list below is complete. Scheduled workflow rules start evaluating the copied documents as soon as the Workflow Service runs, and capture jobs act on their sources as soon as the Capture Service runs.

## Isolation — the part that protects real people

> **WARNING:** A restored copy with production settings still in the database has live outbound email, live exports, and live integration credentials. It **will** email real customers and push real files. Isolation is not optional polish; it is the point of the plan.

No single "disable everything" switch is documented — plan to work through each channel individually:

- **Outbound email.** Workflow notifications send through the server configured under **Admin > System Settings > E-mail Server Settings**. On the copy, clear these settings or repoint them to a test mailbox; with no email server configured, workflow email actions are not even offered. Of the three message channels — Email, Fax, Internal — only **Internal** is inherently safe on a copy.
- **Scheduled workflow rules.** 14 of the 25 workflow trigger types run on timers, not user actions. Review the rule list in workflow administration and disable anything that notifies or exports before the Workflow Service starts.
- **Export actions.** Content-export and data-export actions write files to configured paths, and integration export actions push records to QuickBooks, Sage 50, Workday, Epicor, and Microsoft Dynamics CRM. The Integration Service uses the credentials in the copied database — leave it stopped unless integration testing is the goal, and then point it at sandbox companies first.
- **Capture jobs.** These are destructive to their sources: folder jobs remove the files they import, and email jobs download messages from the mailbox. Disable or repoint every capture job before the Capture Service first starts, or the test box will steal files and mail from production sources.

*[Screenshot: E-mail Server Settings page on the test copy with the production SMTP host removed]*

## Licensing the second install

The license key lives in the database, so a restored production database carries the production license into the test system. A fresh install runs a 7-day full-featured evaluation instead. What a longer-lived test or demo environment should run on is a commercial question — ask your Ademero account representative about non-production licensing before you build.

## Identity and sign-in

The copied database also carries your SSO and Active Directory configuration. The test server's URLs will not match the reply URLs registered with your identity provider (Azure AD, Okta, ADFS), so single sign-on fails on the copy until it is registered separately — or you fall back to forms (username/password) login for testing. If SSO itself is what you're testing, repeat the static `machineKey` setup in the web application's `web.config` on the test server, as on any front end.

## Plan the refresh before you need it

A test environment goes stale. There is no automated refresh: re-copying production is the same manual backup, restore, and file copy — **and the entire isolation list again**, because a refreshed database brings production email, rules, and credentials back with it. Decide the cadence and the owner now, and treat isolation as part of every refresh, not a one-time task.

## Agree on acceptance tests

Define "the test environment works" up front:

- [ ] The login page loads (not an error page)
- [ ] All five services show **Running**, and the `ContentCentral` Windows Event Log shows no repeating errors — a service can show Running while processing nothing
- [ ] A document checks out and back in
- [ ] A test document dropped into a (test) capture source, or a test workflow, processes end to end
- [ ] The installed version (listed as **Ademero Content Central** in installed programs) matches the build you intended on both servers

## Who owns it

Name one owner. A test environment holds **real production documents** — secure it, patch it, and retire it like production, and make its owner responsible for refreshes and for keeping isolation intact.

## When to involve Ademero

Bring your filled-in worksheet to **support** for product questions — restore behavior, isolation settings, acceptance-test results. If you want Ademero to design, build, or maintain the environment for you (or a partner demo system), that is a services conversation — start with your account representative.

## The worksheet

Copy this into your planning document and fill in every line before building:

- [ ] **Purpose:** what exactly are we testing, and could a test catalog in production cover it?
- [ ] **Server:** where the copy runs, and who provides it
- [ ] **Database:** verified backup taken and restored to the test SQL Server
- [ ] **Documents:** storage folders copied in the same window as the database
- [ ] **Connection file:** `ConnectionInfo.xml` on the test server points at the test database
- [ ] **Services held:** Content Central services stay stopped until isolation is complete
- [ ] **Email:** E-mail Server Settings cleared or repointed to a test mailbox
- [ ] **Fax:** outbound fax disconnected on the copy, if you use it
- [ ] **Workflow rules:** scheduled, notification, and export rules reviewed and disabled
- [ ] **Integrations:** Integration Service stopped, or repointed to sandbox systems
- [ ] **Capture jobs:** every job disabled or repointed away from production sources
- [ ] **License:** non-production licensing agreed with your account representative
- [ ] **Sign-in:** SSO re-registered for the test URLs, or forms login planned
- [ ] **Refresh:** cadence, owner, and isolation-on-every-refresh agreed
- [ ] **Acceptance tests:** pass/fail list agreed before the build starts
- [ ] **Owner:** one named person responsible for the environment and its data

## What's next

- [Back up your Content Central database](https://help.ademero.com/content-central/administration/back-up-your-content-central-database)
- [Move Content Central to a new server](https://help.ademero.com/content-central/administration/move-content-central-to-a-new-server)