The Archer Inventory Worksheet
Before you can scope an Archer migration, you have to know what's actually in the instance. This is the discovery document that gets you there — fill it in over a week, not an afternoon.
Print this and work through it with whoever has the deepest Archer knowledge on your team — ideally before that person's availability becomes a question. If the admin who built your instance has already left, expect Section 5 to take the longest.
// Section 1 of 7Instance Basics
Start with the facts that determine your negotiating position and your timeline — version and hosting model affect what export tools are available, and your renewal date sets the outer boundary on how much runway you actually have.
| Archer version | |
|---|---|
| Hosting model (on-prem / hosted / SaaS) | |
| Current admin / owner | |
| Vendor account contact | |
| Support/maintenance contact | |
| Contract renewal date | |
| Contract termination notice period |
// Section 2 of 7Application Inventory
List every custom application in the instance — not just the ones you use daily. Dormant applications still count toward migration scope until you've explicitly decided to kill them in Section 6. Record counts and custom field counts are your best early signal of how much re-mapping effort each application represents.
| Application | Purpose | Record count | Custom fields | Active workflows? | Still needed? |
|---|---|---|---|---|---|
// Section 3 of 7Data Volume Snapshot
A rough count by record type tells you more about migration effort than any narrative description will. Pull these from Archer's reporting module rather than estimating — the actual numbers are frequently larger than teams expect.
| Record type | Active count | Archival / inactive count |
|---|---|---|
| Controls | ||
| Risks | ||
| Issues / Findings | ||
| Vendors / Third Parties | ||
| Policies | ||
| Assessments / Questionnaires | ||
| Incidents | ||
| Other |
// Section 4 of 7Integration and Feed Inventory
Archer instances frequently accumulate scheduled data feeds and integrations that nobody remembers configuring. Check the job scheduler and integration configuration screens directly rather than relying on institutional memory — this section is where the most surprises turn up.
| Integration / feed | Source system | Frequency | Owner |
|---|---|---|---|
// Section 5 of 7Institutional Knowledge Map
This is the section that determines your actual risk level. For each application or workflow of real complexity, name the person who understands it, rate how well that understanding is documented, and flag how likely that person is to be unavailable when you need them. Be honest about the departure risk rating — this document is more useful pessimistic than optimistic.
| Application / area | Who knows it | Documentation status | Departure risk (Low/Med/High) |
|---|---|---|---|
// Section 6 of 7Keep / Archive / Kill Decision Grid
Migration is your best opportunity to shed years of accumulated dead data. For each application or major data set from Section 2, make an explicit decision — actively migrate it, archive it outside the new platform, or kill it entirely. "We might need it someday" is not a decision; if nobody can name a specific use case, it belongs in archive or kill.
| Application / data set | Decision (Keep / Archive / Kill) | Rationale |
|---|---|---|
// Section 7 of 7Regulatory Retention Obligations
Before you archive or delete anything, confirm what you're legally required to keep and for how long. Retention obligations vary by framework and by the type of record — audit trails, incident records, and vendor assessments often carry different retention periods than general operational data. When in doubt, ask legal or compliance counsel before Section 6 decisions become irreversible.
| Record type / framework | Retention period required | Confirmed by |
|---|---|---|