Excel to a multi-user system: what to check before hiring
Before moving Excel to a multi-user system, check whether better workbook collaboration or an existing configurable product meets the need. If custom development is justified, commission a bounded process with documented rules, role permissions and a migration and cutover rehearsal. Copying rows into an application does not prove that operations work.
First check whether you need to leave Excel
Several people editing a workbook does not automatically justify a new system. Microsoft documents Excel co-authoring with compatible versions, supported formats and OneDrive or SharePoint Online storage. Check those conditions with IT before treating file locks as an unavoidable product limitation.
The decision changes when you need control over operations: who may change each record, which states permit an action and how two updates to the same request are resolved. Describe the specific incident you need to prevent. A slow workbook, a broken formula and an approval without an owner call for different interventions.
Do not confuse co-authoring with concurrent automation. The Excel Online (Business) connector documentation says simultaneous modifications to one file from multiple clients or connectors are unsupported and can cause conflicts and inconsistent data. This applies to that connector, checked on November 3, 2026; it is not a general ban on collaboration in Excel.
Compare three approaches using the same business process
Ask each option to complete a representative operation: create a record, correct it, approve it and view it from another role. Include a genuine process exception using fictional data. This matrix is an evaluation framework proposed by Duotach, not a benchmark or a universal recommendation.
| Approach | When to evaluate it | What to verify |
|---|---|---|
| Excel with organized collaboration | Workbook rules and access meet the need | Compatible versions, permissions and recovery |
| Configurable platform | An existing product covers the process | Rules, roles, export and integrations in a test |
| Custom application | A concrete operational gap remains | Record rules, conflicts and accepted migration |
Migrate the business rule as well as the row
Before requesting a quote, choose a bounded process, such as receiving an internal request through to approval. Identify source files, calculated columns, lookup lists, macros, attachments and reports consuming the result. A visible total may depend on an exception known only to the workbook owner.
Map each field: source column, meaning, transformation rule, destination and validation owner. Preserve identifiers as text when leading zeros matter; distinguish blanks from zeros and dates from text that looks like a date. Do not remove duplicates by name without an accepted identity rule.
Agree which history to import, which remains available for reference and how the original source is preserved. Access to samples and test environments containing personal or restricted information must be authorized. A first commercial conversation does not require unrestricted copies of every file.
A fictional test for comparing proposals
Imagine a request workbook with three rows: S-001 pending for 120 units; S-002 approved for 80; S-003 cancelled for 50. The expected result preserves three requests and totals 80 approved units. These are invented test records, not a client case or a Duotach result.
Add another S-002 row with a different quantity. The system should apply the agreed policy: reject the conflict or route it for review while preserving evidence. It must not invent an identity or silently pick the last row. Request an import ledger covering accepted, rejected and pending records so the whole file can be reconciled.
Next, two users open S-001. One changes its quantity; the other tries to approve an older version. The test should demonstrate the contracted behavior: flag the change and require review, or apply another explicit policy accepted by the business. A database alone does not establish that this control exists.
Agree the cutover and treatment of new transactions
The rehearsal and final import happen at different times. New requests, corrections and cancellations may arrive in between. Define a cutover time and time zone, who makes the workbook read-only and how changes since the rehearsal snapshot are transferred.
For each stage, designate one authorized source for recording transactions. If you need to compare both systems, use a reference copy or a reconciliation procedure. Two editable sources without an explicit synchronization rule recreate the original problem.
A rollback plan must cover transactions accepted by the new system. Restoring an earlier workbook does not automatically include them. Agree how they are exported, who reconciles them and which condition postpones cutover. Rehearse in a separate environment with operations and IT owners.
Evidence to request before accepting the migration
Write acceptance criteria before development. Adapt the proposed checks below to your process; they do not certify that a particular application or provider meets them. When a test fails, record the affected data and repeat reconciliation after correction.
A demo using new records may show screens without testing history, permissions or conflicts. Request evidence for the same release candidate and authorized data batch. Complete this review with the custom software handover guide for code, access and documentation.
| Control | Proposed test | Evidence |
|---|---|---|
| Data | Reconcile identities, quantities and states | Record provenance and explained differences |
| Rules | Repeat known calculations and exceptions | Expected versus actual results |
| Permissions | Attempt changes from an unauthorized role | Blocked action outside the screen too |
| Concurrency | Edit and approve different versions | Conflict resolved under the agreed policy |
| Cutover | Include a correction made after rehearsal | Transaction appears once in the destination |
What changes the proposal scope
Compare discovery, rule reconstruction, data cleaning, initial loading, integrations, permissions, cutover rehearsal and support separately. File size is not enough for a quote: a small workbook may contain macros and exceptions affecting the entire process.
Define included processes, who resolves ambiguous records, retained history and acceptance tests. Also agree infrastructure, licenses and ongoing maintenance. A proprietary application does not automatically remove recurring costs or include every future change.
AI may suggest field mappings or help document formulas, but those proposals require review. The final system does not need AI to solve permissions, states or concurrent edits. Acceptance still depends on the agreed rules and data working correctly.
Discuss a system for your operation
Duotach builds custom software for businesses. If your process needs its own application, describe what the workbook records, who uses it, the systems involved and the missing control. The inquiry starts a scope conversation; file assessment and specific tests belong to separately agreed paid work.
The aim is a business process your team can operate and accept with evidence. This guide does not set a universal price, delivery time or saving: these depend on the process, data, dependencies and contracted conditions.
Define the first process
Describe what your workbook records and the control your team needs.
