How to Choose a Document Management System
A six-phase DMS selection process for real estate teams, including requirements, pilot criteria, scoring, rollout, and 12 hard vendor demo questions.
Published September 27, 2026 · By ARC-Files · 24 min read
Published: September 27, 2026 | By ARC-Files
How to choose a document management system starts with your documents, failure modes, and governance requirements, not a vendor demo. A defensible selection process inventories the records, identifies operational failures, separates mandatory requirements from preferences, scores vendors consistently, defines pilot success criteria before testing, and measures adoption after rollout.
The most common selection mistake is beginning with software.
A vendor demonstrates AI search, OCR, dashboards, and workflows. Everyone likes the interface. Six months later, the implementation team discovers that nobody defined which copy of a lease is authoritative, what metadata is mandatory, how retention works after property disposition, or who owns the taxonomy.
The software selection was not the first decision. The operating model was.
Key Takeaways
- Start with a document inventory and failure analysis before writing requirements.
- Separate must, should, and could requirements so every feature does not become equally important.
- Pilot success criteria should be written and approved before the pilot begins.
- Every vendor should be tested against the same real documents and scenarios.
- Ask vendors to demonstrate difficult administrative tasks, not just end-user search.
- Rollout should happen in controlled waves with measurable adoption and a defined pause point.
- If the same problems exist because nobody owns document governance, fix governance before buying another platform.
Why Most DMS Selections Fail Before the Shortlist
A DMS project often starts like this: "We need better document management. Let's see what vendors are out there."
That skips several decisions the vendor cannot make for you. For example: Which documents are governed records? Which systems currently hold authoritative copies? What retrieval failures matter most? Which metadata fields need to be mandatory? Which retention rules exist? Which integrations are genuinely required? Which repositories must remain? Which users need access? What does success look like six months after launch?
ISO 15489-1 explicitly includes analysis of business context and identification of records requirements among the principles supporting effective records management.
Microsoft likewise recommends documenting current business processes, user journeys, storage patterns, governance needs, and collaboration requirements before rolling out SharePoint and OneDrive.
That produces a better starting question: What document problem are we trying to control, and what evidence would prove it has been solved?
The Six-Phase DMS Selection Process
The selection process should produce a concrete artifact at every phase. If a phase ends only with meetings and opinions, it is not finished.
| Phase | Core question | Required artifact |
|---|---|---|
| 1. Document inventory | What do we actually manage? | Document-type register |
| 2. Failure-mode interviews | Where does the current process break? | Ranked pain register |
| 3. Requirements definition | What must the system do? | Must / Should / Could matrix |
| 4. Shortlist | Which vendors deserve a pilot? | Scored vendor matrix |
| 5. Proof of concept | Can the system solve our real scenarios? | Signed pilot success criteria |
| 6. Rollout | Is the system actually being adopted? | Adoption measurement plan |
Each artifact becomes an input into the next phase. Do not skip forward because a vendor demo looks promising.
Phase 1: Build the Document-Type Register
Start by identifying what information the organization actually manages.
For a commercial real estate organization, the register might contain executed leases, lease amendments, assignments, estoppels, SNDAs, title policies, deeds, surveys, Phase I and Phase II ESAs, certificates of insurance, rent rolls, CAM reconciliations, tax documents, vendor contracts, construction closeout files, warranties, capital-project invoices, and closing binders.
Do not begin by counting folders. Folders describe the current storage design. The document-type register should describe the business records.
The Document-Type Register
A useful register includes:
| Document type | Lease Amendment |
| Business owner | Lease Administration |
| Authoritative system today | SharePoint |
| Approximate volume | 4,200 |
| Annual growth | 600 |
| Required metadata | Property, tenant, parent lease, execution date |
| Current retrieval method | Property / tenant folders |
| Sensitivity | Confidential |
| Retention class | Lease records |
| Common downstream users | Legal, operations, asset management |
| Major failure | Amendments disconnected from base lease |
The inventory does not need perfect numbers before work can continue. It does need enough information to distinguish "We have a lot of PDFs" from "We have 4,200 amendments across several markets, and our main failure is identifying which amendment belongs to which controlling lease."
That second statement can become a system requirement.
Phase 2: Conduct Failure-Mode Interviews
Do not ask users "What features do you want?" Users will answer with features they already know.
Ask: Tell me about the last time the current document process failed.
Interview representatives from property operations, lease administration, asset management, legal, compliance, finance, IT, records management, and document administrators.
Look for mechanisms, not general complaints.
Weak finding
Search is bad.
Useful finding
Property managers search only within the property folder. When legal files an amendment in the central legal library, operations does not see it during lease review unless someone already knows it exists.
That finding exposes several possible requirements: cross-library search, common tenant/property metadata, parent agreement relationship, authoritative-document status, and legal/operations access rules.
Another example — Weak
Permissions are confusing.
Useful
Acquired properties receive copies of the previous market's SharePoint permissions. Local admins then manually add users. After two years, nobody can explain why 17 users still have access to one property's legal library.
Now the requirement is not simply "RBAC = yes." It might be permission templates by role, inherited security model, reporting of current access, controlled exception process, and repeatable new-market provisioning.
Produce a Ranked Pain Register
| Rank | Failure | Frequency | Business impact | Root cause | Evidence |
|---|---|---|---|---|---|
| 1 | Amendments missing during lease review | Monthly | High | Repository split + inconsistent metadata | Three recent lease reviews |
| 2 | COIs found after expiration | Weekly | High | Expiration not governed as metadata | Operations interview |
| 3 | New markets use different document types | Every acquisition | Medium-High | No central taxonomy | Compare 4 market sites |
| 4 | Legal cannot prove who changed metadata | Occasional | High | Weak audit procedure | Audit request |
| 5 | Duplicate closing files | Frequent | Medium | No authoritative-record rule | Closing binder review |
Then rank the failures. Not every annoyance deserves a technology project.
Phase 3: Turn Failures Into Must / Should / Could Requirements
Once the failures are documented, convert them into requirements. Avoid requirements such as easy to use, powerful search, AI enabled, secure, or scalable. Those are aspirations, not test cases.
A useful requirement can be tested.
Failure
Users cannot find lease amendments unless they know the property folder.
Requirement
The system must retrieve lease amendments across all portfolio repositories using property, tenant, document type, parent agreement, and execution date without requiring the user to know the physical folder.
Now a vendor can demonstrate it.
Must / Should / Could Matrix
Must
Failure of the requirement removes the vendor from consideration. Examples: Entra ID / required enterprise SSO compatibility, mandatory lease metadata, audit history, retention controls, permission model, bulk export capability, required integrations, defined data-residency requirement.
Should
Meaningful value, but a workaround is acceptable. Examples: automatic metadata suggestions, bulk tagging, configurable dashboards, mobile access, OCR, advanced workflow.
Could
Useful differentiation after core requirements are satisfied. Examples: generative AI summaries, branded portals, optional interface customization, convenience automation.
Why Weighting Matters
Suppose one vendor has excellent AI, excellent UI, great dashboards, and no acceptable retention model. Another has average UI, reliable metadata, strong retention, and strong auditability.
If retention is genuinely mandatory, the first vendor should not win because it accumulated more points from optional capabilities. The scoring framework has to preserve the hierarchy of requirements.
Phase 4: Build the Shortlist Before Requesting Demos
The shortlist should come from documented requirements, not whichever companies appeared first in search results.
A practical shortlist may contain several architecture types: SharePoint with improved governance, SharePoint-native DMS layer, dedicated cloud DMS, metadata-first DMS, full ECM/content-services platform, or specialized legal DMS where legal is the dominant workload.
Related: Best Document Management Software for Real Estate: 7 Criteria That Actually Matter.
Build a Vendor Matrix
Score requirements such as metadata enforcement, portfolio-wide search, retention, audit export, Entra ID/SSO, migration approach, permission model, market provisioning, exit/export, user experience, OCR/extraction, and optional AI — each with a weight and a vendor score backed by evidence.
Do not give the vendor its final score during the first demo. First collect evidence. Then score.
Phase 5: Write Pilot Success Criteria Before the Pilot
This is the most important phase.
Do not start a pilot with: We'll try it for a month and see what everyone thinks. That guarantees ambiguity.
At the end, one user loves the search interface. Another dislikes the colors. IT says the integration worked. Legal says retention was never tested. The vendor says the pilot was successful. Nobody knows whether the original problem was solved.
Microsoft explicitly recommends creating success criteria for a pilot so the organization knows when the pilot is ready to expand. Microsoft also recommends starting with a small pilot, gathering feedback, testing core business processes, and widening rollout only after the expected use cases have been validated.
Define Success First
Before the vendor receives pilot access, write criteria such as:
Search
A lease administrator who does not know the file path must retrieve the correct executed lease and all amendments for five test tenants within two minutes each.
Metadata
Users cannot classify a file as Lease Amendment without Property, Tenant, Parent Agreement ID, Execution Date, and Record Status.
Retention
A retained document must preserve the expected retention state after being moved between approved test locations.
Audit
The pilot administrator must export evidence showing who changed a specified document's metadata and when.
Permissions
A user outside the legal role must be unable to access the privileged test document while retaining access to ordinary property records.
Provisioning
The implementation team must create a new test market using the approved taxonomy, permissions, and library structure without rebuilding configuration manually from scratch.
Exit
The vendor must export a sample set with files and agreed metadata in a documented format.
Put the Criteria into a Signed Pilot Sheet
| Test | Success condition | Owner | Result |
|---|---|---|---|
| Cross-property search | 10/10 test records retrieved | Operations | ___ |
| Lease relationships | Base lease + amendments returned together | Lease Admin | ___ |
| Metadata enforcement | Required fields cannot be bypassed | Records | ___ |
| Audit export | Requested activity exported successfully | Compliance | ___ |
| Retention | Test records behave according to configured rule | Legal | ___ |
| Permissions | Test access matrix passes | IT Security | ___ |
| Provisioning | New market created from standard configuration | IT | ___ |
| Export | Files + agreed metadata leave platform successfully | IT | ___ |
Who Signs Before the Pilot?
At minimum: project owner, IT owner, business owner, and compliance/records owner where applicable.
The signature does not make the pilot bureaucratic. It prevents the definition of success from changing after everyone sees the product.
Twelve Demo Questions Vendors Dislike
A good demo contains fewer slides and more live administration. Give every vendor the same questions.
1. "Upload this badly named document and show me how the system identifies it."
Use scan_00384_FINAL2.pdf. Do not let the vendor prepare the file beforehand. Ask them to classify it correctly.
2. "Leave one mandatory metadata field blank and try to save it."
This distinguishes metadata support from metadata enforcement.
3. "Move this retained document to another library. What happens to retention?"
Ask the vendor to show the retention state before and after the move.
4. "Show me the audit-trail export in its raw format."
Do not accept "Here's our audit dashboard." Ask for the file that would actually be supplied to an auditor or investigator.
5. "Change this document's metadata and show the before-and-after evidence."
You are testing whether audit history covers classification changes, not only file downloads.
6. "Provision a new market live on this call and time it."
Request standard libraries, metadata, permissions, document types, search configuration, and retention. You want to observe how much is reusable and how much is manual.
7. "Show me exactly where our document resides."
Ask them to distinguish file binary, metadata, search index, AI-extracted content, backups, and logs.
8. "Remove this user from the property team. Show me what happens to access."
Test the real permission lifecycle, not the initial permission setup.
9. "Export this document with its metadata, versions, and audit history."
If some components cannot export, identify that before purchase.
10. "Show me how a legal hold overrides ordinary disposition."
If legal hold is a requirement, do not accept a slide describing it. Use a test record.
11. "Break the integration."
Ask: What happens if the PMS/API is unavailable when this document is uploaded? Does the transaction retry? Does it fail silently? Is there an exception queue? Who gets notified?
12. "Show me how we leave."
Ask the vendor to walk through contract termination, bulk export, metadata export, API access, post-termination window, professional services required, and deletion from vendor systems. The exit demo may reveal more about the architecture than the search demo.
Score the Pilot, Not the Sales Presentation
Once every vendor has completed the same scenarios, score them using the evidence. A useful scoring scale is:
- 5 — demonstrated successfully with our test case
- 4 — demonstrated with minor configuration required
- 3 — workable but requires a meaningful workaround
- 2 — major limitation
- 1 — requirement effectively unsupported
- 0 — vendor would not demonstrate or evidence
The zero is important. If a vendor repeatedly answers "We can do that" but cannot demonstrate the requirement, do not score the promise as though it were evidence.
Stakeholder Sign-Off Should Expose Disagreements
IT, operations, and legal may score a platform differently. Do not average those disagreements away immediately. For example:
| Requirement | IT | Legal | Operations |
|---|---|---|---|
| Permissions | 5 | 4 | 4 |
| Retention | 4 | 2 | 4 |
| Search | 4 | 4 | 5 |
| Administration | 2 | 4 | 5 |
A low legal retention score deserves investigation even if the average is acceptable. Ask: What did legal observe that the other teams did not?
A scorecard is valuable because it makes disagreement visible early.
Phase 6: Rollout Needs an Adoption Measurement Plan
Selection does not end when the contract is signed. A document system creates value only if users place documents into the governed process and can retrieve them reliably afterward.
Microsoft recommends piloting SharePoint and OneDrive with a small group, expanding based on feedback, and using phased rollout with pause opportunities rather than a big-bang launch.
Microsoft's migration guidance likewise recommends assessing the source environment, piloting with a limited group, learning from the pilot, and then determining the broader migration schedule.
Build an Adoption Measurement Plan
Track measures such as:
Classification completeness
% of new controlled documents with all mandatory metadata
Search success
% of test retrieval tasks completed without asking another employee
Authoritative-copy accuracy
% of sampled document sets where users identify the correct authoritative record
Exception volume
number of documents routed for metadata correction
Shadow-storage rate
number of sampled files still stored outside the approved repository
Support volume
document-management tickets by category
Provisioning consistency
% of new markets matching standard configuration
User adoption
active users performing expected document tasks
Roll Out in Waves
Example: Wave 1 — pilot property/market. Wave 2 — two additional markets. Wave 3 — one larger market plus legal. Wave 4 — wider portfolio.
At every wave: validate configuration, collect user feedback, review support issues, compare success metrics, pause if core controls fail, and correct before expanding.
A phased rollout is not slower if it prevents a bad configuration from being copied to 40 properties.
Migration Deserves Its Own Validation
If the selected architecture requires moving documents, treat migration as a separate controlled workstream.
Microsoft's file-share migration guidance recommends assessing the source environment before migration, including determining which content is redundant, obsolete, or still relevant. It also recommends pilot migrations before larger cutovers.
A DMS migration should validate total file count, failed files, unsupported formats, metadata mapping, permissions, versions, source/target reconciliation, links, retention state, duplicates, and final cutover.
Do not assume migration tool completed means migration is correct. The business owner should validate representative records.
When to Stop the Selection Process and Fix Governance Instead
Sometimes the correct outcome of a DMS selection project is: Do not buy anything yet.
Stop and fix governance first if the interviews reveal that the main failures are: nobody owns document quality, users disagree over which copy is authoritative, there is no approved taxonomy, retention requirements have never been defined, departments use different names for the same records, there is no decision on where final documents belong, employees store uncontrolled email attachments by habit, or permissions are granted informally with no access model.
A new DMS can enforce rules. It cannot invent the rules.
Example
Suppose three departments disagree on whether an executed amendment belongs under Legal, Property, or Lease Administration.
The immediate reaction may be: We need better software. But the first issue is not storage. The organization has not defined its authoritative-record model.
A better policy may be: one authoritative document, stored in one governed repository, classified by property, tenant, and document type, accessible to each permitted team through search/views, with no department-specific master copies.
Once that decision exists, technology can enforce it. Without it, a new platform merely recreates the disagreement with a newer interface.
Frequently Asked Questions
How do I choose a document management system?
Start with a document-type inventory and interviews that identify specific failure modes. Convert those failures into Must, Should, and Could requirements, score a shortlist consistently, and run the same real-world test scenarios against each vendor. Define and approve pilot success criteria before the pilot begins so the result is measurable rather than subjective.
What should be in a DMS RFP?
A DMS RFP should include document types and approximate volumes, current repositories, metadata requirements, retention and legal-hold requirements, security and SSO, data residency, integrations, migration scope, audit requirements, workflow needs, implementation expectations, support model, export requirements, exit terms, pilot scenarios, and the evaluation scoring methodology.
How long does DMS implementation take?
There is no universal implementation timeline. Scope depends on repository count, migration volume, taxonomy design, integrations, permissions, retention, workflow configuration, user population, and change management. A governance-in-place project can differ substantially from a full repository migration. Vendors should provide a phased implementation plan tied to defined deliverables rather than only a headline duration.
What questions should I ask a DMS vendor?
Ask vendors to demonstrate metadata enforcement, retention after file moves, raw audit export, access changes, new-market provisioning, migration rollback, integration failure handling, data location, legal hold, version export, metadata export, and the complete termination process. Use your own test files and scenarios instead of accepting prepared demonstrations.
Where ARC-Files Fits
ARC-Files, the SharePoint-native document management platform from Al-Rafay Global, should enter the selection process only when the documented requirements fit its architecture.
The relevant scenario is an organization already using Microsoft 365 where the main failures involve SharePoint search, metadata consistency, document governance, retention/compliance controls, permissions visibility, and repeatable market structures.
It should not survive the shortlist if the requirements instead point to high-volume enterprise capture, formal case management, broad non-Microsoft repository federation, or another platform category that better matches the use case.
The same six-phase process should be used whether ARC-Files is one of the candidates or not.
For a deeper vendor-scoring framework, see Best Document Management Software for Real Estate. For architecture questions, see how it works. When the requirements and pilot criteria are already defined, contact us for a product-specific evaluation.
Sources Cited
- ISO 15489-1:2016. The standard includes analysis of business context, identification of records requirements, responsibilities, controls, and processes for creating and managing records.
- Microsoft Learn — Identify business requirements for SharePoint and OneDrive. Microsoft recommends documenting current user journeys, collaboration patterns, business requirements, governance, and adoption needs before rollout.
- Microsoft Learn — Roll out SharePoint and OneDrive. Microsoft recommends a small pilot, explicit success criteria, feedback collection, and broader rollout after expected use cases are validated.
- Microsoft Learn — SharePoint rollout planning. Microsoft recommends phased deployment with pause opportunities and active feedback instead of a big-bang rollout.
- Microsoft Learn — File-share migration guidance. Microsoft recommends assessing the existing environment, determining relevant content, running pilot migrations, and learning from the pilot before broader cutover.
Last updated: September 27, 2026
Keep reading
Suggested Articles
Continue exploring document management, SharePoint governance, and compliance for commercial real estate teams.