Look at the process, not the age of the file.
A large spreadsheet is not automatically a problem. Look for friction that affects the work: people overwriting shared records, approvals hidden in chat, formulas only one person understands, or uncertainty about who changed a value.
An internal tool becomes more relevant when the process needs defined roles, controlled actions, reliable record history, or connections to other systems. First describe the operational problem clearly enough that you could recognise whether a new application has solved it.
Compare three practical alternatives.
| Approach | Consider it when |
|---|---|
| Improve the spreadsheet | The work is flexible, ownership is simple, and validation or clearer structure addresses the main problem. |
| Configure existing software | A product already supports the workflow and its permissions, exports, and integration limits fit your needs. |
| Build an internal tool | Specific process rules or connected actions justify a custom application and an ongoing maintenance commitment. |
Compare the complete operating cost, including setup, subscriptions, migration, training, and maintenance. A custom interface is only useful if the process behind it becomes easier to operate.
Choose one complete workflow for the first scope.
Identify the core record and its lifecycle. A request might move from draft to submitted, approved, and completed. Define which roles can perform each action and which information is required at that point.
Include the reports and exports people need to finish the work. Avoid reproducing every tab before checking whether it still serves a purpose. Keep analysis tasks in a spreadsheet where that remains the more useful environment.
Treat migration as a separate piece of work.
Review a representative sample for duplicate records, missing values, inconsistent dates, attachments, and formulas that encode business rules. Agree the destination fields and decide how uncertain records will be resolved.
Plan how the team will work during the transition, who approves the imported data, and what happens if validation fails. Keep a controlled reference copy of the original data under your retention requirements. Decide when the previous editing process ends so two competing sources of truth do not emerge.
Test the tasks people actually perform.
Acceptance should cover submitting and finding a record, the relevant approval, a denied action, an important change in history, and the required export. Review migrated totals or record counts where they help check completeness.
Let the intended users try representative work. A screen can look complete while requiring an awkward workaround for the team's most common exception.
Give the new tool an operating owner.
Agree responsibility for access, hosting, backups, updates, and support. Document the setup, data export path, known limitations, and the process for future changes. Include these responsibilities in the decision to build, rather than discovering them after launch.
Start with one working example. Bring a sample sheet with sensitive details removed, the roles involved, and the process you want to improve. Explore internal tools development or describe the tool you need.