Spreadsheet to Web App Migration Checklist

A spreadsheet is not automatically a problem. It can remain the simplest tool for a small team exploring data, producing a one-off analysis or running a low-risk process with one clear owner. Migration becomes worth evaluating when the file has quietly turned into shared operational infrastructure: several people edit it, approvals live in messages, formulas encode business rules, access is difficult to limit, and nobody can explain which copy is authoritative.

Look for operational symptoms rather than file size. Repeated entry, conflicting versions, missing history, fragile formulas, delayed approvals, uncontrolled exports and slow reconciliation all point to a workflow problem. The goal is not to reproduce every cell in a browser. It is to design a dependable process with validated inputs, named decisions and useful visibility.

Start by choosing one end-to-end job that causes measurable friction, such as approving a purchase request, assigning a service visit or updating an order exception. A focused custom web application can prove the workflow before the organisation funds a larger platform. That scope discipline also protects the migration from becoming a vague programme to ‘digitise everything’.

Document what happens today without treating the spreadsheet as the process specification. Follow one real item from entry to completion and record who creates it, who checks it, which information is required, what decision changes its status, who can reverse that decision and what happens when information is missing. Include the phone calls, emails and chat messages used to repair exceptions; those hidden handoffs often contain the most important requirements.

For each stage, define the system of record, responsible role, validation rule and escalation path. Replace ambiguous columns such as ‘done’ with explicit states. If a request can be drafted, submitted, returned, approved, rejected, cancelled or reopened, write those transitions down and decide which roles may perform them. The application should make valid work easier and invalid transitions harder.

Turn the map into acceptance criteria that a business owner can test. A useful criterion says an approver can see every request waiting for their decision, open the supporting evidence and record an approval or reason for return. It does not simply say ‘build dashboard’. This clarity lets designers, developers and users agree whether a release completes the intended job.

Do not move years of spreadsheet ambiguity into a cleaner interface. Inventory every source file, tab, formula, lookup, identifier and external reference. Decide which records are active, which history must be retained, who owns each field and how duplicate or incomplete rows will be resolved. Preserve an untouched source copy with restricted access before any cleansing or transformation begins.

Create a field-mapping document from source columns to the new data model. Record data type, required status, allowed values, transformation rule and the person who approves the result. Stable identifiers matter more than display names; two customers called ‘ABC Traders’ should not merge because a script guessed. Where a formula represents a business rule, rewrite the rule in plain language and test it with representative cases before implementing it in code.

Rehearse the migration with a representative subset. Compare record counts, financial or operational totals where appropriate, date ranges, ownership and status distributions. Log rejected rows instead of silently dropping them. Only schedule the final cutover after the team has signed off the reconciliation method, the allowed data-freeze window and the rollback route if the imported records cannot be trusted.

A login page is not an access-control design. List the actions and records each role genuinely needs, deny access by default and enforce authorisation on the server for every request. OWASP recommends least privilege, permission validation on every request and tests for authorisation logic. A person allowed to view a branch report should not gain access to another branch by changing an identifier in a URL or request.

Use the OWASP Application Security Verification Standard as a testable security baseline rather than promising vague ‘industry-standard security’. ASVS 5.0 provides requirements that application owners can use during development, verification and procurement. The chosen assurance scope should match the application's data, exposure and business impact, then appear in the acceptance plan rather than arriving as an afterthought before launch.

Log important business and security events with enough context to investigate problems: authentication attempts, permission failures, approvals, sensitive exports, material record changes and administrative actions. OWASP's logging guidance also warns against recording secrets and sensitive data unnecessarily. Decide retention, access and alerting rules, protect logs from tampering, and test whether the team can reconstruct a failed workflow without exposing passwords, tokens or confidential content.

Security continues after release. NIST's Secure Software Development Framework treats secure practices as lifecycle work. Define dependency updates, restore testing, incident ownership, monitoring and change review before the application becomes operationally critical.

A first release should complete one useful journey, not show fragments of ten future modules. Include the user entry point, permissions, core decision, notification, exception path, reporting view and staff administration required to finish that job. Park secondary automation and advanced analytics until the team has evidence about real usage and bottlenecks.

Run user-acceptance testing with realistic roles and records. Test normal completion, missing data, duplicate submission, rejected approval, unavailable integration, lost connection, incorrect permission and rollback. Record each result against the agreed acceptance criteria. Training should use the same scenarios and explain not only which button to press, but also who owns the next step when the system cannot complete it automatically.

Choose a controlled cutover. Some teams can switch after a short data freeze; others need a limited pilot by location, department or process type. Avoid indefinite parallel operation, because two live sources create reconciliation work and uncertain ownership. Set the exit criteria for the pilot, the authority date for the new system and the conditions that trigger rollback before launch day.

Measure whether the workflow is becoming more dependable, not whether the application contains many features. Useful signals may include completion time, waiting time by stage, correction rate, rejected submissions, recurring exception reasons, unresolved items and the percentage of work completed without offline repair. Select measures that reflect the original bottleneck and review them with the process owner.

Watch how people work around the system. A new shadow spreadsheet, repeated exports or approval decisions returning to chat usually indicates a missing rule, poor usability, weak reporting or unclear ownership. Investigate the reason before adding another feature. The correct response may be a process change, better training, a permission adjustment or improved data quality rather than more code.

Maintain an evidence-led improvement list. Fix security, reliability and data-integrity risks first; then remove frequent friction; then consider integrations. Review access when roles change, restore backups, test major workflow changes and keep technical ownership documented. Use a free growth audit to turn the current spreadsheet and exception list into a first-phase roadmap.