Excel to Web Application Migration Services

Updated September 2026

Converting a business spreadsheet into a web application is a short project with a long tail. The build is usually weeks. The part that decides whether it works is who owns the code afterwards, who your team calls when a rule changes, and whether the supplier read your workbook before quoting. Ask eight questions before you sign. The most important one is whether you get the source code in your own repository on day one.

I spent years at McKinsey watching companies buy software. The spreadsheet migrations that failed rarely failed on the code. They failed because nobody agreed what the spreadsheet actually did before somebody started rebuilding it, or because the finished system belonged to the supplier and every small change needed a purchase order.

What an Excel to web migration actually involves

Stage one, read the workbook. A good supplier opens the file before quoting. They are looking for how many tabs are live, which are archives, where the lookups point, which formulas carry the pricing logic, and how many people touch it. This takes hours, not weeks, and it is where the estimate comes from.

Stage two, agree the model. Tabs become tables. Columns become fields. Formulas become rules. The conversation that matters here is about the things the workbook never wrote down: who logs in, who may approve, what "done" means, and which formulas everyone already knows are wrong. Skipping this stage is the single most common cause of a rebuild that nobody uses.

Stage three, build. With AI writing most of the code and an engineer reviewing it, a first working version of a single workbook now takes days rather than months. Ours does. That changes the shape of the project, because you can look at a real screen in week one instead of a specification in week six.

Stage four, run both. The spreadsheet and the app run side by side for a few weeks. You compare totals. This is the stage inexperienced suppliers skip and experienced buyers insist on.

Stage five, switch off the spreadsheet. If you never actually retire the file, you have added a system instead of replacing one, and your costs went up.

Eight questions to ask before you sign

Four red flags

A fixed price with no discovery. Nobody can price a workbook they have not opened. A fixed price offered before anyone reads the file is either padded heavily or it will become a change order.

A demo that is not your data. Ask to see your own spreadsheet in the demo. Any supplier that can build in weeks can load a sample of your rows.

"We will replace all of it." A migration that starts with the whole spreadsheet estate at once takes a year and gets cancelled. Start with the one workbook that hurts most, ship it, then take the next.

No mention of the people who use it. The estimator who has run the pricing file for nine years decides whether this succeeds. If the supplier has not asked to talk to them, they are building a version of your business they invented.

What it costs

The honest range is wide, because a two tab tracker and a thirty tab pricing engine are different projects. A traditional development agency quoting a custom internal tool will typically talk in tens of thousands. AI assisted delivery has moved that floor a long way down.

Our own numbers, so you have a reference point. A done for you build sprint starts at $2,000. An ongoing build partnership starts at $1,500 a month. Hosting a finished app starts at $9.99 a month with no per user seat fees. And you can convert a workbook yourself for free first, which is the cheapest way to find out how big the job really is.

For the full arithmetic, including the cost of keeping the spreadsheet, read how much it costs to replace a spreadsheet with a custom web app.

Enterprise spreadsheet to portal conversion

At larger companies the request usually arrives as a portal. Suppliers or branches or clients need to see their own rows and submit their own updates, and today that happens by emailing spreadsheets back and forth.

The technical work is the same as a single workbook conversion plus three things. You need accounts and per organisation permissions, so each party sees only their own data. You need an audit trail, because somebody will dispute a number. And you usually need one integration, most often to the finance system, so the portal is not a third place where the truth lives.

Sequence it one workbook at a time even here. The first release should serve one real group of users end to end. A phased rollout gives you a working system in weeks and the option to change direction, and a big bang gives you a steering committee.

What this looks like when it works

RSB is a steel contractor whose estimating logic lived in one workbook. We rebuilt it as a custom web application in six weeks from kickoff to deployment. Estimates now take 62% less time and cost 40% less to produce. The write up is here.

The reason it worked was not the speed. It was that the estimator sat in the model conversation, so the rules in the app match the rules in his head, and the app is theirs to change.

How we work

We are an AI first shop with human engineers. Our coding agent, Leonardo, reads your workbook and writes the application. A human engineer reviews every build before it goes near your data. The output is a standard Ruby on Rails application on a PostgreSQL database, and the code lives in your own GitHub repository. There are no per user fees.

We have converted more than 400 spreadsheets this way. You can try the same conversion yourself in about 60 seconds with the free Excel to app converter, and use the result as a specification whether you hire us or not.

Frequently asked questions

How long does an Excel to web application migration take?

A single workbook is usually days to a few weeks for a working first version, then a few weeks running in parallel with the spreadsheet before you retire it. The published RSB case study ran six weeks from kickoff to deployment.

Do we keep our formulas and macros?

Formulas become rules in code, which is usually an upgrade because the rule is written once instead of copied down 4,000 rows. VBA macros are rewritten rather than imported. The detail is in keeping your formulas and VBA macros.

Should we hire a development company or use a no code platform?

Compare on the two questions that bite later: who owns the code, and what does it cost per user at your headcount in three years. The arithmetic for a 12 user internal tool is worked through in Glide vs Softr vs Airtable vs a custom build.

Can you work with our IT department's requirements?

Yes. Because the output is a standard Rails application in your own repository, your IT team can review it, host it themselves, or hand it to another supplier. That is the main reason we build it that way.

What if we only need one report published, not an application?

Then do not buy software. Convert the sheet to an HTML table with our free Excel to HTML converter and paste it into your page. If the list has to be live, searchable and public, the middle option is to convert the spreadsheet into a website, which is far less work than a migration project.

Pricing, case study figures and product facts are LlamaPress's own, published at llamapress.ai/pricing, llamapress.ai/services and the RSB case study, checked September 2026.