# Solve With Software: full page text The complete text of the strategy pages and the /systems/ section of https://www.solvewithsoftware.com, for AI assistants. The short index is https://www.solvewithsoftware.com/llms.txt. Generated 2026-09-14 from the site's content modules; the live pages are the canonical versions. Solve With Software Ltd is a Colchester-based software consultancy that takes over and modernises stranded business systems for UK SMEs. Every engagement starts with a free one-hour consultation; the assessment that follows is from £395 + VAT and prices each stage before the client commits. --- # Hub index pages # Legacy system modernisation, by technology URL: https://www.solvewithsoftware.com/modernise Title: Legacy Modernisation by Technology Description: Every technology we take over, VB6 and Access to .NET Core and SSRS: what each needs, the migration paths, what it costs. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over and modernises business systems built on the technologies listed here, from Visual Basic 6 and Microsoft Access to .NET Core, React Native and SQL Server Reporting Services. Each page says what that technology needs in 2026, which migration paths work, and what the assessment establishes before anything is priced. The method is the same on every one: stabilise first, then modernise in stages with the old system as the fallback. ## Which page to start on The one for the technology the business works in day to day. A system is often several of these at once: a VB6 front end on a SQL Server database, Crystal Reports on top, an export to Sage. Start with the front end, because that is where the business rules live and where the modernisation choice is made. The database, reporting and integration pages cover the parts that usually move last, and each links to the others where the work overlaps. Mobile apps have their own set of pages at the end. The questions there come in a different order: signing keys, store accounts and the build tooling the stores accept come before any modernisation. ## What every technology here has in common Three routes, whatever the stack. Keep it and make it safe to change: source under version control, a build that works on a current machine, a test environment, the database on a supported version. Modernise in stages: new screens or services alongside the old ones, sharing the data, one process at a time. Replace alongside: a new system grows next to the old one on the same data and takes over process by process. The data moves once, or not at all. Nothing touches live until it has been built and tested on a copy, then run in staging alongside the live system with the data reconciled. The old system stays available as a fallback until the new one has proven itself. Every stage is priced before you commit to it. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) is from £395 + VAT and produces a report with a fixed price for each route. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) has its own page. ## The technology isn't listed The list is the technologies with a page written, not the limit of what we take over. Kentico and Umbraco sit closest to the DNN page, FileMaker to Microsoft Access, Drupal 7 and Magento 1 to old PHP. Bring it to the free consultation (https://www.solvewithsoftware.com/book-consultation); the assessment works the same way on any of them. Built on an AI or no-code platform rather than a language? Lovable, Replit, Bolt, Bubble, Power Apps and the rest have their own set of pages (https://www.solvewithsoftware.com/rescue), because what you can take out of each differs. ## Support deadlines across these technologies The dates that decide when a system stops receiving security updates. Checked 4 September 2026; each technology page carries the detail. | Technology | Support position | |---|---| | Visual FoxPro | Support ended January 2015; 32-bit only | | Visual Basic 6 | IDE unsupported since 2008; the runtime is supported for the life of Windows 11 | | ASP.NET Web Forms | Never ported to modern .NET; no upgrade path | | .NET Core 2.1 to .NET 7 | Out of support | | SQL Server 2016 | Extended support ended 14 July 2026 | | SharePoint Server 2016 and 2019 | Support ended 14 July 2026 | | .NET 8 and .NET 9 | Support ends 10 November 2026 | | ColdFusion 2021 | Extended support ends 10 November 2026 | | PHP 8.2 | Security support ends 31 December 2026 | | Crystal Reports 2020 | Maintenance ends 31 December 2026 | | Windows Server 2016 | Support ends 12 January 2027 | | SQL Server 2017 | Extended support ends 12 October 2027 | | Ionic Appflow | Closes 31 December 2027 | | .NET 10 | Long-term support to November 2028 | | SSRS 2022 | The last version; supported to 11 January 2033 | A system past its date keeps running. What it loses is security updates, and each year fewer people can work on it. ## Questions Q: Our system uses several of these. Which page applies? A: The one for the part the business works in, usually the front end. The database, reporting and integration pages cover the rest, and the assessment looks at the whole system whichever page you came in on. Q: What if our technology isn't on the list? A: The list is what has a page, not the limit of what we take over. Book the free consultation and say what the system is built in; the assessment works the same way on any of them. Q: What do you modernise to? A: Open technology in your own accounts: .NET and the web for business systems, Flutter for mobile apps that need rebuilding, SQL Server or a managed cloud database for the data. The full source code and ownership transfer to you on final payment. Q: Is it cheaper to replace than to modernise? A: Sometimes, and the assessment says which for your system rather than guessing. It prices each route as a fixed number: keep and stabilise, modernise in stages, replace alongside. The cost page explains what moves the price. --- # AI-built app rescue, by platform URL: https://www.solvewithsoftware.com/rescue Title: AI-Built App Rescue by Platform Description: Stalled app from Lovable, Replit, Bolt, Bubble, Power Apps or Cursor? What each platform exports, what's missing, how we finish it. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software finishes apps that were built on an AI or no-code platform and stalled before the business could rely on them. What can be taken out differs by platform: Lovable and Bolt export real code, Bubble exports none, Replit and Base44 keep the back end behind, and Power Apps and Zoho Creator only run on the vendor's platform. Each page below says what comes out, what is usually missing, and whether finishing or rebuilding is the better route. ## Why the platform decides the route What you hold at the moment the app stalls: the code, the data, the hosting, or none of them. That is set by the platform, and it decides whether the fastest route is to finish what exists or to rebuild from it. Lovable, Bolt, v0, Replit, FlutterFlow and the coding assistants (Cursor, Claude Code, Codex) produce ordinary code you can export or already hold. Base44, Power Apps and Zoho Creator run the app on their own platform; the data and the logic can be read out, the running system cannot. Bubble exports no code at all, so the app is rebuilt with the Bubble workflows as the specification. Zapier and Make are a case of their own: the automations became the system, and the work is to build the system they were standing in for. ## What is usually missing The screens are usually the finished part, and they are the specification for everything else. What the builder skipped is the engineering underneath: authorisation that keeps one customer's records from another, integrity rules in the database, a test and staging environment, error handling, backups, and a deployment in accounts the business owns rather than the builder's. On mobile, the store accounts and the signing keys. Each page lists what its platform tends to leave out. ## The order of work First, a home of its own: the code in your repository, the database and hosting in your accounts, the secrets rotated. Then the foundations above, put under the app while it keeps running as it is. Then the unfinished features, in order of value to the business, each released when it has been tested. Where the platform cannot be left, the same order applies to the rebuild, with the platform app kept running alongside until the new one has proven itself. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) is from £395 + VAT and establishes what exists, what is missing and what each route costs, as fixed prices. ## What each platform lets you take away The export position of each platform, as checked on 4 September 2026. Each page carries the detail and the date. | Platform | Code | Data | Runs elsewhere? | |---|---|---|---| | Lovable | React and Supabase code via GitHub sync | In Supabase, or in Lovable Cloud | Yes | | Replit | Exports | Database, secrets and hosting stay in Replit | Yes, once rehomed | | Bolt | React front end exports | Back end usually not built yet | Yes | | v0 | Next.js screens export | No system behind them yet | Yes | | FlutterFlow | Flutter project, on the Pro plan | Firebase or Supabase | Yes | | Cursor, Claude Code, Codex | Already yours | Wherever you put it | Yes | | Base44 | Screens come out; the back end is closed | Exports | No; rebuilt | | Power Apps | Power Fx source is readable | Dataverse or SharePoint, exportable | No; runs only on Microsoft's platform | | Zoho Creator | Structure and Deluge scripts as a .ds file | CSV | No; Deluge runs only on Zoho | | Bubble | None | Exports | No; rebuilt | | Zapier and Make | Scenario definitions, not code | In the connected apps | Replaced by a system that owns the process | Where the last column says no, the screens and the data still shorten the rebuild: they are the specification and the migration source. ## Questions Q: Can you finish it inside the platform instead of moving it? A: Where the app is internal, the stakes are modest and the platform's limits are not what stalled it, yes, and the Base44, Power Apps and Zoho Creator pages say when that is the better answer. Where the business depends on the app or needs to own the data and the code, it moves. Q: Does the app keep running while you take it over? A: Yes. The takeover starts with a copy in your own accounts and a test environment. The version your team uses stays as it is until the new build has proven itself alongside it. Q: Do you need the person who built it? A: Helpful for an hour, not required. The code, the data and the people who use the app carry enough of the story, and most takeovers happen without the original builder. Q: Which platforms aren't listed? A: Airtable, Softr, Glide, Retool, AppSheet, Knack and Caspio have no page yet. They are hosted platforms, so the Base44, Power Apps and Zoho Creator pages describe the position: the data and the logic come out, the running app does not. --- # The situations we take on URL: https://www.solvewithsoftware.com/problems Title: Legacy System Problems We Solve Description: No documentation, too risky to change, replace or modernise, a stalled AI-built app: four situations and what we do in each. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over business systems in four situations, each with its own page: no documentation and the developer gone, a system too risky to change, a choice between replacing and modernising, and an AI-built app that stalled. Each page describes the situation as it usually presents, what can be established in the first few days, and the route out. The free consultation is where you say which one is yours. ## Which page is yours **The developer has gone and nothing is written down:** no documentation (https://www.solvewithsoftware.com/problems/no-documentation). **Every change breaks something else, so nobody changes anything:** too risky to change (https://www.solvewithsoftware.com/problems/too-risky-to-change). **The system works, but the question of replacing it keeps coming back:** replace or modernise (https://www.solvewithsoftware.com/problems/replace-or-modernise). **Most of an app exists, built in Lovable, Replit, Cursor or Bubble, and the last part won't come:** stalled AI-built app (https://www.solvewithsoftware.com/problems/stalled-ai-built-app). Two of these often apply at once. An undocumented system is usually also the one nobody dares change, and the replace-or-modernise question follows from both. Start with the page that matches the day you are having; each links to the others. ## What the four have in common The system is unmapped rather than broken. The rules the business depends on are in the code, the database and the people who use it, and not yet written down in one place. The first job in every case is to do that: read the code, read the data, sit with the users, and put what the system does on paper with the risks and the options against it. That is the assessment (https://www.solvewithsoftware.com/legacy-system-assessment), from £395 + VAT, and it ends in a fixed price for each option. From there the work is staged whichever situation you started in: the system kept running, changes built and tested on a copy, then run in staging alongside live with the data reconciled, then live, with the old version as the fallback. ## What the first days establish in each situation | Situation | Established first | Usual route | |---|---|---| | No documentation | What the system does, from the code, the database and its users, written down with the dependencies | Stabilise, then modernise in stages | | Too risky to change | A test environment and the map of what depends on what, so a change can be tried without touching live | Small safe changes, then stages | | Replace or modernise | The six questions: what is sound, what is not, what the data is worth, what the business needs next | Keep, modernise or replace, each priced as a fixed number | | Stalled AI-built app | What the platform exports, what is missing underneath, whether the data model holds | Finish on your own technology, or rebuild from the screens | Each row is the assessment's output for that situation, and each page shows what the report contains. ## Questions Q: What if our situation is more than one of these? A: That is the usual case. An undocumented system is often the one nobody dares change. Start from whichever page matches today, and the assessment covers the whole system regardless. Q: Do we need to know what the system is built in? A: No. Knowing helps, and the technology pages go into the detail for each stack, but the first days of the assessment establish it if nobody is sure. Q: What if the system is fine and we just need someone to look after it? A: Then the answer is support rather than modernisation: stabilised first, then a care plan. The legacy software support page covers it. Q: Where do we start? A: A free one-hour consultation, online or by phone, about your system. From there we size the assessment, from £395 + VAT, and give you an exact price before you commit. --- # Strategy pages # A software developer in Colchester, on-site across Essex, Suffolk and London URL: https://www.solvewithsoftware.com/essex-suffolk-london Title: Software Developer in Colchester, Essex Description: Colchester software consultancy that takes over and modernises business systems. On-site in Essex, Suffolk and London, remote UK-wide. Founded 2012. Last reviewed: 2026-09-04 Solve With Software is a software consultancy based at North Colchester Business Centre, founded in 2012. We take over the business systems companies across Essex, Suffolk and London still depend on, understand how they work, stabilise them and modernise them one safe step at a time. On-site when your system needs it, remote for the rest of the UK. ## What we do for businesses in Essex, Suffolk and London We take over business systems, stabilise them, modernise them and add AI to them. The systems are the ones companies run on: a VB6 order book from 2004 (https://www.solvewithsoftware.com/modernise/vb6), an Access database that grew into the whole operation, a .NET application whose developer retired, a spreadsheet that became the system, or a React app whose agency stopped replying. The path is the same for every one of them. A free one-hour consultation, a legacy system assessment (https://www.solvewithsoftware.com/legacy-system-assessment) sized to your system from £395 + VAT, then a written report with costed options and a fixed price for each. The work that follows runs in stages, with working software at the end of every stage. ## Where do you come to? **Colchester and the rest of Essex, Suffolk, and London, in person.** We're based at North Colchester Business Centre, off the A12. Chelmsford, Braintree, Witham and Maldon are under an hour. Ipswich, Bury St Edmunds and the Suffolk coast are the same the other way. London is an hour by train from Colchester to Liverpool Street, which is how we reach clients in the City and the East End. Cambridge and Norwich are about the same drive as Bury St Edmunds, and Kent is over the Dartford crossing, so a site visit in any of those is on the table too. The rest of the UK is remote: screen sharing, access to the code, and calls with the people who use the system. Most of an assessment can be done that way for most systems. The consultation decides which yours is. ## Why on-site matters for a takeover A system is never only what's on the screen. It's the report the sales team builds in a spreadsheet because the system can't produce it, the printout on the wall by the despatch desk, the server that one person knows how to restart. None of that shows up on a screen share. So an assessment includes a site visit when the system needs one. We sit with the people who use it and watch the work go through it. That's where the risks and the opportunities show up. The person who visits is the person who leads the work. ## Sectors Haulage, construction, legal, healthcare, financial services, education and membership organisations. Haulage and construction in particular are Essex trades, and the operations platforms behind them are the kind of system that grows for fifteen years and then outlives the people who built it. We describe our work by sector and system rather than by client name; the detail is on the About page (https://www.solvewithsoftware.com/about). ## Part of Colchester Marc Allington, our founder, started Colchester Dev Club (https://www.colchester.dev/) and built Colchester.Network (https://www.colchester.network/), a community platform for local businesses. Colchester.Network sat on a registered domain for years because the build cost was too high. AI-assisted development brought that cost down, and it shipped in eight weeks. ## What it costs The consultation is free. The assessment is from £395 + VAT, with an exact price before you commit. After that, every option in the report carries a fixed price, so an overrun is our risk rather than yours. Payment terms and the care plan are on the pricing page (https://www.solvewithsoftware.com/pricing). ## Built here - **Founded in Colchester in 2012.** Solve With Software Ltd, company number 08200237, registered office at North Colchester Business Centre, 340 The Crescent, Colchester, Essex CO4 9AD. - **Colchester.Network**, a community platform for local businesses, designed and built in Colchester and shipped in eight weeks. - **Colchester Dev Club**, founded by Marc Allington. - **On-site assessments** across Essex, Suffolk and London, and within reach of Cambridge, Norwich and Kent, as part of every engagement that needs one. ## Questions Q: Do you only work with companies near Colchester? A: No. On-site work covers Essex, Suffolk and London, and reaches Cambridge, Norwich and Kent; the rest of the UK is remote, and most assessments can be done remotely for most systems. Being local matters most when the system needs someone in the room, and the consultation decides whether yours does. Q: Is a site visit included in the assessment? A: When the system needs one, yes. The consultation decides, and the assessment price reflects it. Some systems can be understood entirely over a screen share; others need us in the room with the people who use them and with the server. Q: Our system was built by a local developer who has retired. Can you take it over? A: Yes. It's one of the most common situations we see. The assessment establishes what you have: source code, documentation, a database you can access, or only a running installation. Each is workable, and the report sets out the options with a fixed price for each. Q: Do you work with London businesses? A: Yes, on-site. Colchester to Liverpool Street is about an hour by train, which puts the City and the East End in reach for a day inside your system. Q: Can everything be done remotely? A: Often, yes. Screen sharing, access to the code and calls with the people who use the system cover most of an assessment. Where a system needs a visit, we say so on the consultation. --- # Legacy software support and maintenance URL: https://www.solvewithsoftware.com/legacy-software-support Title: Legacy Software Support and Care Plans Description: Support for systems the original developer left behind: VB6, Access, .NET, SQL Server, old PHP. Stabilised first, then a care plan. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software supports and maintains legacy business systems that the original developer or supplier no longer looks after: VB6, Microsoft Access, .NET Framework, SQL Server, old PHP, and recent stacks whose agency has stopped replying. We take the system over, make it safe to change, and keep it running. Modernisation comes in stages, when you want it and not before. ## Who it's for Your software still works. What it doesn't have is anyone behind it. The developer retired. The supplier stopped supporting the version you run, or stopped trading. The one person who understood it has moved on. So it does its job every day, and nobody touches it. Support means someone to call, and a system that has been made safe to change: for the Windows update, the server restart, the new starter who needs an account, the report a customer asks for that it can't produce. ## What supporting a legacy system involves Stabilise first. Then maintain. Modernise only when you choose to. - **Stabilise.** Get the source code under version control, or recover it if it's missing (https://www.solvewithsoftware.com/problems/no-documentation). Make sure there's a backup and that it restores. Write down how the system is built and deployed, so that knowledge no longer sits with one person. Fix anything that's failing now. - **Maintain.** Fixes, small changes, new users, reports, the occasional integration. Keep it on supported infrastructure, or plan the move before the infrastructure it runs on reaches end of life. - **Modernise, in stages, when you want to.** Once the system is stable and understood, modernising it stops being a leap (https://www.solvewithsoftware.com/problems/too-risky-to-change). New screens over the same data, an API, AI features where they pay back. Each stage priced before you commit to it. Or leave it as it is, supported, for as long as it serves you. ## What we can support Most of what UK businesses run on. - **The old guard:** Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6), Microsoft Access, Delphi, FoxPro, Classic ASP, WinForms, .NET Framework and Web Forms, SQL Server from 2000 onwards, Crystal Reports, SSRS (https://www.solvewithsoftware.com/modernise/ssrs), JasperReports (https://www.solvewithsoftware.com/modernise/jasperreports), Sage integrations (https://www.solvewithsoftware.com/modernise/sage-integrations), and the spreadsheet that runs everything. - **The new legacy:** React, Angular, Node, PHP and Laravel, .NET Core, Bubble, Power Apps, and apps left half-finished in Lovable, Replit or Cursor. If yours isn't on the list, ask. The consultation is free and takes an hour. ## You don't have to replace it Support can be the whole engagement. Plenty of systems are sound and neglected, which is a different thing from broken. If the assessment says the sensible course is to keep it running, we'll say so and quote for that. Modernisation is an option the report puts a price on, not a condition of being supported. ## What it costs Support is priced by the assessment, so the price fits the system. It starts with a free consultation and a legacy system assessment (https://www.solvewithsoftware.com/legacy-system-assessment) from £395 + VAT. That's where the system gets understood, and where the stabilisation work is scoped and given a fixed price. Once a first stage of work is done, the care plan applies: 18% of that stage's cost a year, covering support, hosting, small changes and priority access. Monthly by direct debit, 30 days' notice to cancel. Work outside the agreed scope is quoted before you commit to it, at £850 a day. The full terms are on the pricing page (https://www.solvewithsoftware.com/pricing). ## How it starts A free consultation, then the assessment, then a stabilisation stage. On the consultation we go through what the system does, what's failing and what you need from support. The assessment produces a written report with the risks and a fixed price for making the system safe to change. That first stage is where support begins: source control, backups, documentation, and whatever is broken now. ## The risks of running unsupported software Two kinds. Dates in the calendar, and knowledge that lives in one place. Windows Server 2016 support ends in January 2027. SQL Server 2016 security updates ended in July 2026 for most licence holders. The analogue phone lines some systems still dial, fax or alert over are switched off in January 2027. A system can run for years without incident and become a problem on one of those dates. The other risk is concentration. If one person holds the knowledge, the passwords or the only copy of the code, the first job of support is to change that: the code in version control, the build written down, the passwords in a vault the business controls. ## How we approach it One accountable lead, open technology, and nothing changed until it's understood. The person you speak to on the consultation leads the work. Anything we build or change runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. The old system stays available as a fallback until you say otherwise. ## What a support arrangement includes The care plan is a published product, not a bespoke retainer, so its terms are the same for every client: - **Support** for the system as documented in the assessment report and the first stage of work. - **Hosting**, where we host it, on supported infrastructure. - **Small changes**: a new report, a new field, a new user role, agreed as part of the plan. - **Priority access** to the lead developer who did the work. - **Price**: 18% of the first stage's cost a year, monthly by direct debit, 30 days' notice to cancel. - **Outside the plan**: quoted before you commit, at £850 a day. Before any of that, the assessment produces a written report with the system's risks and a fixed price for the stabilisation stage. ## Questions Q: Can you support a system you didn't build? A: Yes. That's most of what we do. The assessment is how we get to know it: a few days inside the system with the people who use it, reading the code and whatever documentation exists, then a written report and a fixed price for stabilising it. Q: Our software company has stopped supporting the system. Can you take it on? A: Usually, yes. It depends on what you have: the source code, a database you can access, or only a running installation. Each is workable, and the assessment tells you which situation you're in and what it means for the options. Q: We don't have the source code. Is that a problem? A: It's a constraint, not a dead end. Sometimes the code can be recovered from the installed system or an old backup. Sometimes the right answer is to keep the running system supported while a replacement is built alongside it, sharing the same data. The assessment establishes which. Q: It runs on an old server. Do we have to move it? A: Not immediately, and not blindly. The first job is to make sure the server is backed up and can be rebuilt. Then the assessment sets out the options: keep it where it is with the risks stated, move it to supported infrastructure, or modernise the application so the server stops mattering. Q: How quickly do you respond? A: The care plan includes priority access to the lead developer, and response times are agreed in the plan rather than promised on a web page. Outside a plan, work is quoted and scheduled like any other. Q: Can we modernise later, once it's stable? A: Yes, and that's the usual order. Once the system is stable and understood, modernising it in stages is a series of priced decisions rather than a leap. The report sets out the options. You take them when you're ready, or not at all. --- # Legacy system assessment URL: https://www.solvewithsoftware.com/legacy-system-assessment Title: Legacy System Assessment from £395 Description: From £395 + VAT. A few days inside your system, then a written report: the risks, where AI would pay back, and costed options, each at a fixed price. Last reviewed: 2026-09-04 A Solve With Software legacy system assessment is a few days inside your business system with the people who use it, then a written report: what the system does and what depends on it, where the risks are, where AI would pay back, and costed options with a fixed price for each. It starts with a free one-hour consultation and costs from £395 + VAT, with an exact price before you commit. ## Who it's for You depend on a system that nobody is confident about any more. Maybe the developer who built it has retired, or the company that sold it has stopped answering. Maybe the documentation describes a version from years ago (https://www.solvewithsoftware.com/problems/no-documentation), or there's a server nobody wants to restart. The business has outgrown it, but replacing it feels like a leap in the dark. Old or recent makes no difference. A VB6 application from 2004 and a React app from 2021 whose agency stopped replying are the same problem: your business runs on it and can't move it forward. The assessment is the first step. It's also the last one you commit to before you know what the options cost. ## What happens It starts with a free hour, online or by phone. We go through what the system does, what's wrong with it and what you want from it. From that we size the assessment and give you an exact price. Nothing is paid until you say yes. Then we spend a few days inside the system. We sit with the people who use it and watch the work flow through it. We read the code and whatever documentation exists. We look at the data, the hosting, the integrations, and the spreadsheets that have grown up around it. On-site when the system needs it, remote when it doesn't. The person doing this is the person you spoke to on the consultation. If a system needs more hands, we bring them in, working to the same lead. ## What the report contains Four things. - **What the system does, written down in one place.** You know your system. The report puts that knowledge on paper: the processes it runs, the data it holds, what depends on it and what it depends on. From then on it doesn't live only in the heads of the people who've been there longest. - **Where the risks are, and which ones matter.** An operating system out of support, a backup nobody has tested lately, a licence that expires next year, a password only one person holds. Each one rated: urgent, or theoretical. - **Where AI would pay back.** Reading paperwork into the system, drafting replies, answering questions from your own data. And where it wouldn't, so you don't spend money on hype. - **Costed options.** Stabilise and extend what you have, modernise it in stages, or replace it. Each with a fixed price and a recommended order of work. The report is yours. Take it to us, another developer, or nobody. ## You probably don't need to replace everything Most systems we look at are sound and neglected, which is a different thing from broken. The right answer is often to stabilise what's there and extend it: modern screens over the same data, an API so it can talk to the tools you've bought since, AI where it pays for itself. Sometimes it's a staged rebuild, with the new system growing alongside the old one, screen by screen, sharing the same data, so your team keeps working throughout. And sometimes the answer is to leave it alone and put the money elsewhere. If that's what the evidence says, that's what the report says. The keep, modernise or replace decision has a page of its own (https://www.solvewithsoftware.com/problems/replace-or-modernise). ## Your data Nothing happens to it during the assessment. We read; we don't change. What we do look at is how it's structured, how clean it is, and how it would move if it had to. When work does follow, it never touches your live data until it has proven itself somewhere else. We build and test against a copy in a test environment, then run it in staging alongside the live system, migrating, checking and reconciling the data there first. Only when the tests have shown it's safe does anything connect to live, and the old system stays available as a fallback until you're confident. ## What it costs From £395 + VAT, sized on the consultation, with an exact price before you commit. A single-user Access database and a twenty-year-old order processing system with forty users aren't the same job, so the price is set once we know which you have. It's payable in advance. The consultation is free. Everything after that is priced by the report: a fixed price for each option, so an overrun is our risk rather than yours. Payment terms, what's included and what isn't are on the pricing page (https://www.solvewithsoftware.com/pricing), and what moves the price up or down (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) has a page of its own. ## How long it takes A few days inside your system, then the report. The scope is set on the consultation, so you know before it starts how much of your team's time it needs. Most of that time is theirs, because they're the ones who use it. ## The risk of skipping it Quoting an unseen system is a guess, and guesses get paid for later. A developer who prices a rewrite from a phone call has priced what they imagine your system to be. The business rules inside an old system are worth more than the technology around them, and they're the first thing a rewrite loses when nobody has mapped them. Doing nothing has dates attached. Windows Server 2016 support ends in January 2027. SQL Server 2016 security updates ended in July 2026 for most licence holders. The analogue phone lines some systems still dial, fax or alert over go in January 2027. A system that has run for years without incident can become a problem on a date in the calendar. ## How we approach it Understand first. Then stabilise. Then modernise one safe step at a time. Marc Allington leads every assessment. He has built business systems in VB, Access, SQL Server and .NET as well as on the web, in the cloud and with AI, so an old system is familiar ground. Everything we build afterwards runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## What every report contains Every assessment report follows the same structure, so you know what you're buying before you buy it: 1. **Summary for the board.** One page: what the system is, what state it's in, what we recommend and what it costs. 2. **What the system does.** Processes, screens, data, integrations, and who depends on each. 3. **Technical state.** Language and framework versions, hosting, backups, source control, licences, and the support status of each, with dates. 4. **Risk register.** Each risk with its likelihood, its impact on the business, and whether it's urgent or theoretical. 5. **Where AI would pay back.** Specific jobs in your business, and the ones we wouldn't touch. 6. **Options with fixed prices.** Stabilise and extend, modernise in stages, or replace. Each priced, sequenced, and with its trade-offs stated. 7. **Recommended first stage.** What we'd do first, why, and what you'd have working at the end of it. The structure is the same whether your system was built in 2004 or 2024. ## Questions Q: Do we have to use you for the work after the assessment? A: No. The report is yours. Take it to us, another developer, or nobody. It's written so that any competent developer can price the options from it. Q: Is the assessment on-site or remote? A: Whichever the system needs. Some systems can be understood remotely with screen sharing and access to the code. Others need us in the room with the people who use them, and with the server. The consultation decides, and the price reflects it. On-site visits cover Essex, Suffolk and London; the rest of the UK is remote. Q: What do you need from us? A: Access to the system and its code if you have it, an hour or two with each of the people who use it most, and whatever documentation, contracts and licences exist. If there's no code and no documentation, say so on the consultation. That's common, and the assessment is planned around it. Q: What if you find the system should be left alone? A: Then that's what the report says, with the reasons and what to watch for. Sometimes keeping an old system alive is the right answer. If it is, we'll tell you and quote for that instead. Q: Our system was built recently. Does the assessment still apply? A: Yes. A React or Node app whose agency stopped replying, a Bubble or Power Apps build nobody can extend, or an app half-built in Lovable or Replit are assessed the same way. The questions are the same: what does it do, what state is it in, and what are the options. Q: Why is there a charge for the assessment? A: Because it's real work, and it produces something you keep: a written report with the risks, where AI would pay back, and costed options you can take to any developer. It costs a fraction of the work it prices, and it's the only way to give you a fixed price instead of a range. --- # What does it cost to modernise a legacy system? URL: https://www.solvewithsoftware.com/legacy-system-modernisation-cost Title: What Legacy System Modernisation Costs Description: Assessment from £395 + VAT, then a fixed price per option. What drives the cost of modernising a bespoke system, and why an unseen range is a guess. Last reviewed: 2026-09-04 Solve With Software doesn't publish a price range for modernising a system nobody has seen, because it would be a guess. What we publish is how the price is arrived at: a free one-hour consultation, an assessment from £395 + VAT, and a written report with a fixed price for each option, days after we start. The cost is driven by how many processes the system runs, the state of its data, what it connects to, and whether the source code exists. ## Why there's no price range on this page Because nobody can price a system they haven't looked inside. Two order-processing systems can look identical from the outside, and one can take several times the work of the other to modernise, depending on what's in the code and the data. A developer who gives you a range from a phone call has priced what they imagine your system to be, and the difference between that and what it is arrives later as a variation order. So we price the other way round. A few days inside the system first, then a fixed price for each option. An overrun is then our risk, not yours. ## What drives the cost In roughly the order they matter: - **How many processes the system runs.** Orders, quotes, invoicing, stock, scheduling, reporting. Each is a stage, and each stage has a price. A system that does three things costs less than one that does fifteen, however old either is. - **The state of the data.** Clean, constrained data moves quickly. Data with duplicates, free-text fields that mean four things, and twenty years of half-finished migrations takes longer to move and reconcile, and the reconciliation is where the time goes. - **What it connects to.** Sage (https://www.solvewithsoftware.com/modernise/sage-integrations), Xero, a warehouse system, a customer portal, a scheduled export someone relies on. Every integration has to be understood and either kept working or replaced. - **Whether the source code exists.** With source, the rules can be read. Without it (https://www.solvewithsoftware.com/problems/no-documentation), they have to be rediscovered from behaviour and data, which is slower. - **How many people use it, and how.** Six users at desks is one problem. Sixty users, some on phones, some customers, is another. - **Regulation.** Audit trails, retention, access controls. Legal, financial and healthcare systems carry more of this, and it has to be designed in from the start. - **Where it needs to run.** Staying on your server, moving to the cloud, or both for a while. What doesn't drive it much: the age of the technology. A well-structured VB6 system (https://www.solvewithsoftware.com/modernise/vb6) can be cheaper to modernise than a badly structured one from 2021. ## What makes it cheaper than starting from scratch The hard part is already paid for. (https://www.solvewithsoftware.com/problems/replace-or-modernise) Working out what a system needs to do is the most expensive part of any software project, and your current system has already done it. It's a living specification. Your team knows what they'd change. Your data comes with you. Stages help too. Modernising one process at a time (https://www.solvewithsoftware.com/problems/too-risky-to-change) means the first price is for one process, and the business gets something working before committing to the next. And small systems are often the quickest wins: an Access database with six users can be the first project. ## How the price is set 1. **A free consultation.** An hour on the system. From it we size the assessment and give you an exact price for that. 2. **The assessment (https://www.solvewithsoftware.com/legacy-system-assessment).** From £395 + VAT, payable in advance. A few days inside the system, then a written report. 3. **The report.** Each option, stabilise and extend, modernise in stages, or replace, with a fixed price and a recommended first stage. Real numbers, days after we start. 4. **Each stage.** Priced before you commit to it. 40% on signature, 40% at the first working version, 20% on handover. The report is yours. Take it to us, another developer, or nobody. ## The prices that are published Everything with a defined scope has a price on the site: - **The assessment**, from £395 + VAT, sized on the consultation. - **The care plan**, 18% of a stage's build cost a year, covering support, hosting, small changes and priority access, monthly by direct debit, 30 days' notice to cancel. - **Work outside an agreed scope**, £850 a day, quoted before you commit. - **Included in every build**: 30 days of fixes after launch, data migration, full source code and ownership on final payment, handover documentation. The full terms are on the pricing page (https://www.solvewithsoftware.com/pricing). ## Reading other quotes Three things to look for. A day rate with no fixed scope, which means the risk of an overrun sits with you. A price that was given before anyone looked inside the system, which means it's a guess. And a "phase two" that holds everything you asked for, which means the phase one price isn't the price. None of those makes a supplier dishonest. They make the number provisional. ## How we approach it Understand first, then price. Marc Allington leads every assessment, and the price in the report is the one you pay. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment, so what you pay for is yours. ## The numbers that are fixed | Item | Price | Status | |---|---|---| | Consultation | Free, one hour | Published | | Assessment | From £395 + VAT, exact price before you commit | Published | | Each stage of work | Fixed price in the assessment report | Set per system | | Payment per stage | 40% signature, 40% first working version, 20% handover | Published | | Care plan | 18% of the stage's build cost a year | Published | | Out-of-scope work | £850 a day, quoted first | Published | | Fixes after launch | 30 days, included | Published | Anonymised cost bands from finished projects will be added here as case studies are published, so the drivers above can be read against real examples. ## Questions Q: Can't you give us a ballpark? A: Not one we'd stand behind. A figure given before anyone has looked inside the system is a guess, and you'd plan around it. What we can give you is a fixed price for the assessment on the consultation, and a fixed price for the work days after the assessment starts. Q: Would it be cheaper to use an offshore developer? A: Cheaper per day, often. Whether it's cheaper per outcome depends on how much specification and management you can do yourself. If you have someone technical to direct the work, offshore can work well. If you don't, the cost usually reappears as rework. Q: We have a small budget. Is it worth talking? A: Yes. The first stage is one process, and small systems are often the quickest wins. The assessment will tell you what one stage costs for your system, and you decide from there. Q: Why is there a charge for the assessment? A: Because it's real work, and it produces something you keep: a written report with the risks, where AI would pay back, and costed options you can take to any developer. It costs a fraction of the work it prices, and it's the only way to give you a fixed price instead of a range. Q: What happens if the work takes longer than you thought? A: The price doesn't change. A fixed price means the risk of an overrun is ours. If the scope changes because you ask for something new, that's quoted separately before we do it. --- # ASP.NET Web Forms modernisation URL: https://www.solvewithsoftware.com/modernise/aspnet-web-forms Title: ASP.NET Web Forms Migration Description: Web Forms never reached modern .NET. We migrate to ASP.NET Core one page at a time behind a proxy, the old site serving the rest. From £395 + VAT. Last reviewed: 2026-09-04 ASP.NET Web Forms was never ported to modern .NET, so a Web Forms application can't be upgraded, only replaced. Solve With Software does that one page at a time: the new ASP.NET Core application runs behind a reverse proxy alongside the old site, sharing login and session, and takes over pages in order of value while Web Forms carries on serving the rest. The data layer and the business logic underneath usually upgrade and are shared by both. ## Where Web Forms stands It runs, and it will keep running for as long as .NET Framework does, which is tied to the Windows version it ships with. Nothing is switching it off on a date. What it can't do is move. There is no Web Forms on modern .NET. New libraries don't target it, new developers haven't learned it, and every year the gap between it and the rest of your systems widens. The server it runs on has a date, too: Windows Server 2016 support ends in January 2027. So a Web Forms application isn't an emergency. It's a migration that gets more expensive each year it waits. ## What we usually find inside Pages with the logic in the code-behind. A Web Forms application from its era typically has the business rules in the page event handlers, a data layer that may be shared or may be copied into each page, user controls that grew into small applications of their own, and a session that holds far more than it should. Reports, exports and scheduled jobs often hang off the same project. The valuable part is the rules and the data model, as with any legacy system. The pages themselves are the part that has to be rebuilt, and the point of the staged approach is to rebuild them without stopping the business. ## How a page-by-page migration works 1. **Map the application.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) lists every page, control, data access path and integration, and sorts the shared code into what can be upgraded and what has to stay with the old pages. 2. **Upgrade the shared code first.** Business logic and data access move to a library both applications can use, so the rules exist once. Entity Framework 6 usually moves to EF Core here. 3. **Stand up the new application behind a proxy.** An ASP.NET Core site sits in front of the old one, with a reverse proxy passing through any page it doesn't yet own. Microsoft's adapters share authentication and session between the two, so users see one application. 4. **Move pages in order of value.** Each page is rebuilt (Razor Pages, MVC or Blazor, chosen once for the whole application), tested against a copy, run in staging alongside the old page on the same data, checked by the people who use it, then switched. The old page stays reachable until the new one has proven itself. 5. **Retire Web Forms** when the last page that matters has moved. Each stage has its own fixed price, and each ends with working software. ## Razor Pages, MVC or Blazor? **One choice, made once, for the whole application.** Razor Pages is the closest in shape to Web Forms (a page, its code behind it) and the easiest for a team that knows Web Forms to read. MVC suits applications that already separate their logic well. Blazor suits screens with a lot of interaction, and can replace controls within a Web Forms page during the migration. The assessment recommends one from what's in your application and how your team works. ## Your data Usually SQL Server, and it stays where it is. Old and new applications share the same database throughout the migration, so there's no data move and no day when two versions of the truth exist. Where the data access layer changes, the new queries are tested on a copy, then in staging against the live schema, before anything connects to live. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Web Forms application it counts the pages and controls, sorts the shared code, and prices the proxy setup and the first pages as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks The big-bang rewrite, first. A Web Forms replacement built in full before going live is the project that stalls. The proxy approach exists so that every page ships on its own. The second risk is the server. Windows Server 2016 goes out of support in January 2027, and a Web Forms application on it goes with it. Moving the old site to a supported server is a stage that can happen before, during or instead of the migration, and the assessment says which. ## How we approach it Shared code first, then a proxy, then pages by value. Marc Allington has built on .NET Framework for years and builds on modern .NET now, so both ends of the migration are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. The wider .NET Framework picture (https://www.solvewithsoftware.com/modernise/dotnet-framework) has its own page. ## The technical checklist for a Web Forms migration | Check | Why it matters | |---|---| | Page and control count, and which are still used | Sets the size of the migration. Dead pages don't move. | | Where the business logic lives: code-behind, shared library, stored procedures | Logic in code-behind has to be extracted before the page is rebuilt; logic in a library or the database is shared for free. | | Data access: EF6, raw ADO.NET, typed datasets | Typed datasets and old ADO.NET are the slowest to modernise and the most worth doing. | | What's in session, and who reads it | Session sharing between old and new is solved by the adapters, but only for what's serialisable. | | Authentication: forms auth, Windows auth, something custom | Decides how login is shared across the proxy. | | Third-party controls and licences | Old commercial grids and report viewers often have no modern equivalent under the same licence. | | Hosting: IIS on which Windows Server | The server date may set the order of work. | | Tests, source control, build | Usually thin. The safety net comes before the first page moves. | Each answer goes into the report with its stage and a fixed price. ## Questions Q: Can't Web Forms just be upgraded to .NET 10? A: No. Web Forms doesn't exist on modern .NET, and Microsoft has said it won't. Every Web Forms page has to be rebuilt. The shared code underneath usually can be upgraded, which is why we start there. Q: Will users see two different applications during the migration? A: No. A reverse proxy sits in front of both, and Microsoft's adapters share login and session, so it looks and behaves like one application. Users notice a page getting faster, not a page changing sites. Q: Our Web Forms application is in VB.NET. Does that matter? A: The pages have to be rebuilt either way, and the rebuilt pages are usually in C#. The shared VB.NET libraries can often be upgraded as they are. Q: How long does a Web Forms migration take? A: It depends on the page count and how much logic is in the code-behind, which the assessment measures. The shape is the usual one: shared code and the proxy first, the first pages live within about six weeks, then pages in order of value, each priced before you commit. Q: Can we stop partway through? A: Yes. The proxy arrangement is stable for as long as you like. Some applications run half-migrated for years by choice, with the pages that matter modernised and the rest left alone. --- # Classic ASP modernisation URL: https://www.solvewithsoftware.com/modernise/classic-asp Title: Classic ASP Modernisation Description: Classic ASP runs on IIS, but VBScript is being retired from Windows. We take it over and move it to ASP.NET Core a page at a time. From £395 + VAT. Last reviewed: 2026-09-04 Classic ASP still runs on Windows Server as part of IIS, but the language most Classic ASP applications are written in, VBScript, is being retired from Windows in phases: deprecated now, disabled by default from around 2026 to 2027, then removed, and when it goes the pages stop. Solve With Software takes a Classic ASP application over, moves the data and the rules into the open, and rebuilds it as ASP.NET Core one page at a time behind a proxy, with the old site serving the rest until the last page has moved. ## Where Classic ASP stands Two different answers, and both matter. Classic ASP itself is still a supported component of IIS. Windows Server 2025 ships it, so on paper it's supported well into the 2030s. VBScript is the other answer. Microsoft has announced its retirement from Windows in phases. In the current phase it's deprecated but installed and switched on by default. In the next, from around 2026 to 2027, it becomes an optional feature that's off by default. Then it's removed. Classic ASP uses the same VBScript engine as the rest of Windows, so a Classic ASP application written in VBScript stops working on a server where VBScript isn't installed. The practical position in September 2026: your Classic ASP application runs today, and the clock on the language underneath it is running. A server rebuild or an operating system upgrade is when it usually bites. ## What we usually find inside Twenty years of a business in a few hundred .asp files. Include files everywhere, SQL written inline in the pages, a mix of VBScript and the occasional JScript, session variables doing the work of a data model, and a database that's usually SQL Server and usually fine. The rules are in there. They're just spread across pages in a way that nobody has mapped, which is why the first job is to map them. ## The paths **Contain it.** Pin the server. Document how it's built and deployed. Make sure VBScript stays installed on the server through any update, and that a rebuild of the server is a known procedure rather than a discovery. This buys time, and for a small internal application it can be the whole answer for a while. **Migrate to ASP.NET Core, page by page.** The usual path. A new application sits behind a reverse proxy alongside the old site and takes over pages in order of value. The inline SQL becomes a proper data layer; the VBScript rules become C#. The old site keeps serving whatever hasn't moved. **Replace it.** Right when the application's shape no longer fits the business, or when the pages are so tangled that porting them costs more than designing from the rules. Even then, replace alongside, with the data shared and the old site kept until the new one has proven itself. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) reads the pages and prices each path as a fixed number. ## How a page-by-page migration works 1. **Map it.** Every page, every include, every SQL statement, every session variable and every integration, written down as a system description with the rules made explicit. 2. **Safety net.** Source control, a documented build of the old site, a test environment, a backup that's been restored. 3. **A proxy in front.** The ASP.NET Core application handles the pages it owns and passes everything else through to Classic ASP. Login is bridged so users see one site. 4. **Data layer once.** The inline SQL is gathered into one place, so the rules exist once and both applications can use them. 5. **Pages in order of value.** Each rebuilt, tested on a copy, run in staging on the same data, checked by the people who use it, then switched. The old page stays reachable until the new one has proven itself. 6. **Retire Classic ASP** when the last page that matters has moved, before or after VBScript's removal, on your schedule rather than Microsoft's. ## Your data Usually SQL Server, occasionally Access, and either way it's the part that carries forward unchanged. Old and new applications share the same database throughout, so there's no data move unless an Access file has to become a SQL Server database first. Any change to the data is tested on a copy, then in staging, before anything connects to live. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Classic ASP application it counts the pages, maps where the rules and the SQL live, and prices containment, migration and replacement as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting The obvious one has a plan attached: VBScript is leaving Windows in phases, and a Classic ASP application in VBScript leaves with it. The date isn't fixed, which is worse than a fixed date, because it arrives as a surprise during a server rebuild. The slower one is people. Classic ASP hasn't been taught for twenty years. The developer who can read yours is the same one who's retiring. ## How we approach it Map it, contain it, then move it on your schedule. Marc Allington has built web applications in Classic ASP and builds on ASP.NET Core now, so both ends are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a Classic ASP takeover | Check | Why it matters | |---|---| | VBScript or JScript, and any COM components | VBScript is the engine being retired. COM components compiled in VB6 or C++ are a second dependency with their own risks. | | Page and include count, and which pages are still used | Sets the size of the migration. Dead pages don't move. | | Where the SQL lives | Inline SQL in pages has to be gathered into a data layer before the rules can exist once. | | Session and application variables | What's held in session, and which pages read it, decides how the old and new sites are bridged. | | Database: SQL Server, Access, something else | Access moves to SQL Server first; SQL Server stays put. | | Integrations: email, payment, file uploads, other systems | Each is rebuilt on the new side and has to be found first. | | Server: Windows version, IIS version, whether VBScript is installed as a feature | Sets the date pressure and the containment steps. | | Source control and a documented build | Usually neither. The safety net comes before any page moves. | Each answer goes into the report with its stage and a fixed price. ## Questions Q: Is Classic ASP still supported? A: As an IIS component, yes, and Windows Server 2025 ships it. The language underneath, VBScript, is a different story: it's being retired from Windows in phases, and Classic ASP written in VBScript stops when it goes. That's the reason to plan now rather than the reason to panic. Q: When exactly will VBScript be removed? A: Microsoft has published phases rather than a date: deprecated now, off by default from around 2026 to 2027, removed later. The risk is that the change arrives with a server rebuild or an operating system upgrade rather than on a day you chose. Q: Can you keep our Classic ASP site running while we decide? A: Yes. Containment is the first stage: pin the server, document the build, make sure VBScript stays installed through updates, prove the backup restores. That buys the time to migrate on your schedule. Q: Can the VBScript be converted to C# automatically? A: Not usefully. The pages mix markup, logic and SQL in a way that a converter reproduces rather than fixes. We read them, gather the rules and the SQL into one place, and rebuild the pages from that. Q: How long does a Classic ASP migration take? A: It depends on the page count and how tangled the rules are, which the assessment measures. The shape is the usual one: containment and the proxy first, the first pages live within about six weeks, then pages in order of value, each priced before you commit. --- # ColdFusion modernisation URL: https://www.solvewithsoftware.com/modernise/coldfusion Title: ColdFusion Modernisation Description: ColdFusion 2021 support ends 10 November 2026. Upgrade to 2025, move to Lucee, or leave CFML one page at a time. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over ColdFusion applications the business still depends on: CFML written between 2000 and 2015, on a version Adobe no longer patches, by a developer who's moved on. ColdFusion is still a live product, so there are three paths: upgrade to ColdFusion 2025 and modernise in place, move the same code to the open-source Lucee engine, or leave CFML one page at a time behind a proxy. The assessment reads the code and prices each as a fixed number. ## Where ColdFusion stands Adobe still ships it. ColdFusion 2025 is current, on a subscription licence, and supported to April 2030; ColdFusion 2023 is supported to May 2028. Everything before that is out of support: 2018 ended in July 2023, and 2021's core support ended on 10 November 2025 with extended support ending 10 November 2026. An application on CF 9, 10 or 11 has been unpatched for years. The other engine matters. Lucee is an open-source CFML server that runs most ColdFusion code with small changes, on a current Java, with no licence fee. For a business that wants to keep its CFML and stop paying per core, it's a serious option, and it's where a lot of the CFML community has gone. What hasn't changed is the shape of the applications: a set of .cfm pages with the logic in them, a database, a few custom tags, written when that was how web applications were built, and the same page-by-page problem (https://www.solvewithsoftware.com/modernise/classic-asp) Classic ASP has. ## Three paths **Upgrade in place to ColdFusion 2025.** Keep the code, move the runtime. Deprecated tags and functions get fixed, security settings tightened, and the application ends on a supported version with Adobe behind it. Costs the subscription, keeps everything familiar. **Move to Lucee.** The same code, an open-source engine, a current Java underneath, no licence. Some ColdFusion-specific tags and behaviours need adjusting, which the assessment lists. Right for a business that wants to keep CFML and cut the cost. **Leave CFML in stages.** Where the application would be rebuilt anyway, or where nobody left can hire for CFML. The new system is built alongside in .NET or the web stack, one page or one process at a time behind a proxy, with ColdFusion still serving what hasn't moved. Users see one change at a time. **Often the first or second, then the third.** Get it supported first, because that removes the risk; then decide the rest with the pressure off. ## The staged path 1. **Get it running on a current machine**, from source control, against a copy of the database. Missing custom tags, hard-coded paths and a datasource nobody can recreate are the first surprises. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) does this first. 2. **Safety net.** A test environment, a staging environment, and tests around the processes that matter. 3. **Move the runtime**, to ColdFusion 2025 or Lucee, fixing the deprecated and engine-specific code the compatibility check lists. Run in staging against the live schema, reconcile, switch. 4. **Secure it.** Old CFML applications were written before most of today's attacks; input handling and the admin console are checked and fixed. 5. **Replace page by page**, where leaving is the plan, behind a proxy, in order of risk and value. 6. **Retire the old server** when the last page has moved. Each stage has its own fixed price and each ends with the application safer than before. ## Your data Usually SQL Server or MySQL, sometimes Access or Oracle, and it stays where it is. A runtime move changes how queries are run, so the data layer never meets a change until the change has proven itself somewhere else: tested against a copy in a test environment, then run in staging against the live schema with results reconciled, before anything connects to live. ## Can this be done gradually? **Yes. A runtime move is one switch, rehearsed in staging.** A rebuild goes one page at a time behind a proxy, with the ColdFusion application serving the rest, and can pause between pages with everything still working. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a ColdFusion application it gets the code running on a copy, runs the compatibility check against ColdFusion 2025 and Lucee, maps every page and datasource, and prices the three paths as fixed numbers alongside what each costs to run. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting The date, first: 10 November 2026 for ColdFusion 2021, and everything older has been unpatched for years. ColdFusion has had serious remote vulnerabilities, and an old application facing the internet on an old engine is the exposure a security questionnaire will find. Then the people: CFML developers are hard to hire, and the one who knows this application is a single point of failure. ## How we approach it Get it running, make it safe, move the runtime, then decide the rest. Marc Allington reads CFML as one more server-side language from the same era as Classic ASP, and builds in the .NET and web stacks a ColdFusion application moves to. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a ColdFusion application | Check | Why it matters | |---|---| | ColdFusion version and licence, Java version underneath, Windows or Linux | Sets the urgency and what the runtime move costs. | | Does it run on a current machine from source, against a copy of the database? | If not, that's stage one. Missing custom tags and datasources are the usual reason. | | Compatibility check against ColdFusion 2025 and Lucee | Lists the deprecated tags and engine-specific code each path has to fix. | | Every page, and which ones carry the logic | Maps the application; decides the order of a page-by-page rebuild. | | Datasources, and whether they can be recreated | Often the only copy of a connection string is on the live server. | | Input handling, session handling, admin console exposure | Where old CFML applications are attacked. | | Integrations: email, payment, file drops, scheduled tasks | Every one has to keep working through a runtime move. | | Tests, source control, deployment process | Usually none. The safety net comes first. | Each answer goes into the report with its path, its consequence and a fixed price. ## Questions Q: Is ColdFusion dead? A: No. Adobe ships ColdFusion 2025 on subscription and supports it to 2030, and Lucee is an active open-source engine. What's dead is the version most old applications are on. Staying on CFML and moving the runtime is a real option. Q: What is Lucee, and can our code run on it? A: An open-source CFML engine on a current Java, with no licence fee. Most ColdFusion code runs on it with small changes; the assessment's compatibility check lists which tags and behaviours in your application need adjusting. Q: ColdFusion 2025 is subscription only. Do we have to pay it? A: Only if you stay on Adobe's engine. Lucee removes the licence; leaving CFML removes the engine. The assessment prices all three paths alongside what each costs to run each year. Q: Can we replace it one page at a time? A: Yes. A proxy in front routes each path to the old ColdFusion application or the new one, so users see a single site while pages move in order of risk and value. It's the same approach we use for Classic ASP. Q: How long does a ColdFusion modernisation take? A: It depends on how many pages there are and which path the assessment recommends. The shape is the usual one: running and safe first, on a supported runtime within about six weeks, then one stage at a time, each priced before you commit. --- # Crystal Reports replacement URL: https://www.solvewithsoftware.com/modernise/crystal-reports Title: Crystal Reports Replacement Description: Crystal Reports 2020 maintenance ends 31 December 2026. We extract what each report does and rebuild the reports, output for output. From £395 + VAT. Last reviewed: 2026-09-04 Crystal Reports is the part of a legacy system most often forgotten in a modernisation and the part the finance team notices first. SAP has ended support for Crystal Reports 2016, ends mainstream maintenance for 2020 on 31 December 2026 and for 2025 a year later, and has moved its investment elsewhere. The reports keep running after those dates; the runtime embedded in your application stops being patched. Solve With Software extracts what each report does, its query, its formulas and its layout, and rebuilds the reporting layer on the modernised system, with every report checked against the old output before the old one is switched off. ## Where Crystal Reports stands Winding down on a published schedule. Support for Crystal Reports 2016 ended on 31 December 2024. Mainstream maintenance for Crystal Reports 2020 ends on 31 December 2026, and for Crystal Reports 2025 on 31 December 2027. SAP's investment has gone to its cloud analytics products rather than to Crystal. The reports don't stop on those dates. What stops is patches, fixes and standard support for the runtime, which in a legacy business system is usually a 32-bit component embedded in a VB6, Delphi, Access or .NET application, installed on every PC that prints. The runtime that came with the application is often older than any of those dates already. ## Why reports get forgotten, and why that's expensive Because they sit outside the code. A modernisation maps the screens, the data and the rules, and the reports live in .rpt files that nobody opened. Then the new system goes live, the month-end runs, and the finance director asks where the aged debtors report is. Reports are also where a surprising amount of business logic lives. A Crystal formula that decides what counts as overdue, a selection rule that excludes a customer type, a subreport that pulls from a table the main system forgot. Those rules are part of the system, and they only exist in the report. ## What replacing Crystal Reports involves 1. **Inventory.** Every .rpt file, where it's called from, who runs it and how often. Half are usually dead. The ones that remain are the specification. 2. **Extract what each report does.** The query or the stored procedure, the formulas, the grouping and totals, the parameters, the layout. Written down as a description, because the .rpt format isn't one you can read. 3. **Choose the reporting layer** for the modernised system. Reports built into the application in most cases; a reporting product where the business needs ad-hoc analysis; sometimes both. 4. **Rebuild each report** and run it side by side with the Crystal version on the same data. Totals, row counts, and the layout the finance team recognises. A report doesn't switch until it matches. 5. **Retire the runtime** when the last report has moved, and with it the 32-bit dependency on every PC. Each report is a small stage of its own, which is why the work can be priced as a fixed number and done in the order the business cares about. ## Embedded in an application, or stand-alone? **Two different jobs. Crystal embedded in a VB6, Delphi, Access or .NET Framework application is part of modernising that application: the reports move when the system does, and they're usually the last stage.** Stand-alone Crystal, where the finance team runs reports against the database directly, is a reporting migration on its own, and it can happen without touching the application at all. The assessment establishes which you have and prices each accordingly. ## Your data Untouched. Reports read; they don't change. The rebuilt reports run against the same database as the Crystal ones, side by side, until each matches. Where the reporting layer needs its own tables or views, they're built and tested on a copy, then in staging, before anything connects to live. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For Crystal Reports it inventories the .rpt files, identifies which are alive, extracts what a sample of them do, and prices the rebuild report by report as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting An unpatched 32-bit runtime on every PC that prints, with the dates above already passing. A Windows update that stops the runtime registering on a new machine, which is how most Crystal problems arrive. And the rules that live only in the reports being lost in a modernisation that didn't inventory them. ## How we approach it Inventory first, then match every report before switching it. Marc Allington has built and replaced reporting layers on the systems Crystal usually sits inside, VB6, Access and .NET, so the runtime and its habits are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a Crystal Reports migration | Check | Why it matters | |---|---| | Crystal version and runtime version, and where the runtime is installed | Sets the support date and the 32-bit dependency footprint. | | Every .rpt file, who runs it, how often, and from where | Dead reports don't move; live ones are the specification. | | What each report reads: tables, views, stored procedures, and which database | Some reports read from tables the main system forgot; that has to be found. | | Formulas, selection rules and subreports | Where the business rules hide. Each is extracted and written down. | | Parameters and scheduling | How the report is run, and by what. | | Output formats: print, PDF, email, export | Each is a requirement of the new reporting layer. | | Embedded or stand-alone | Decides whether the reports move with the application or on their own. | Each answer goes into the report with a fixed price per report. ## Questions Q: Will our Crystal reports stop working when support ends? A: No. The reports keep running. What ends is patches and support for the runtime, which is a 32-bit component on every PC that prints. The practical failure usually comes with a Windows update that stops it registering on a new machine. Q: Can the new reports look the same as the old ones? A: Yes, where that matters, and it usually does for the reports the finance team sends outside the business. Each rebuilt report is run side by side with the Crystal version until the totals, rows and layout match. Q: What should replace Crystal Reports? A: It depends on who runs the reports. Reports the application produces for its users are built into the modernised application. Reports the finance team builds themselves need a reporting product, and the assessment recommends one from how they work. Q: Our reports have a lot of formulas. Do those get lost? A: Not if they're inventoried. Formulas and selection rules are business rules, and they're extracted and written down before the report is rebuilt. That's most of the work and the reason it's done report by report. Q: Can you replace the reports without touching the application? A: If the reports run stand-alone against the database, yes. If they're embedded in the application, they move as part of modernising it, usually as the last stage. The assessment establishes which you have. --- # Delphi application modernisation URL: https://www.solvewithsoftware.com/modernise/delphi Title: Delphi Application Modernisation Description: Delphi is alive, so the choice is real: upgrade to current Delphi, or leave for .NET or the web in stages, BDE and Unicode included. From £395 + VAT. Last reviewed: 2026-09-04 Delphi is unusual among the systems Solve With Software takes over, because the language is still alive: Delphi 13 is current, and an application from Delphi 7 can in principle be brought up to it. So the first decision is whether to stay in Delphi and modernise, or to leave it for .NET or the web in stages. What usually forces the decision is the data layer: the Borland Database Engine, deprecated for two decades and unpatched since 2002, is still underneath most of the old Delphi systems we see. ## Where Delphi stands Alive, and owned by Embarcadero, who release a new version most years and support upgrading a project from any earlier one. That's the difference from VB6 or FoxPro. A Delphi application isn't stranded by its language. It's stranded by what surrounds it. Most old Delphi business systems use the Borland Database Engine for data access, and the BDE was deprecated around 2000, has had no security updates since 2002, and hasn't been part of the Delphi installer since XE8. Applications from before Delphi 2009 aren't Unicode, which matters the moment a customer's name has an accent in it. Third-party VCL components from the era often have no current version, or no findable licence. And the developers who wrote Object Pascal for a living are, like VB6 developers, retiring. So a Delphi system usually runs fine and can't be built, or can be built and can't be changed safely, or can be changed and only by one person. ## What we usually find inside Readable code. Object Pascal ages well. The forms are in DFM files that describe every control, the logic is in units that can be followed, and the business rules are usually where you'd expect them. The problems are underneath: BDE aliases pointing at Paradox tables or an old SQL Server driver, string handling from before Unicode, components that only compile on a Delphi version nobody has installed, and a build that lives on one machine. ## Stay in Delphi, or leave it? **Stay, and modernise in Delphi.** Move the project to a current Delphi version. Replace the BDE with FireDAC, Embarcadero's current data access layer, and move Paradox or dBase tables to SQL Server. Convert to Unicode. Replace or update the third-party components. The application keeps its shape and its screens, and it's supportable again. This is the right answer when the application does its job, the business wants it as it is, and someone can be found to maintain Delphi. **Leave, in stages.** Modern screens over the same data, one process at a time, in .NET or on the web, with the Delphi application still running against the same SQL Server database until the last process has moved. The right answer when the business needs the system outside the office, when the Delphi developer pool is the risk, or when the application's shape no longer fits. **Both, in that order.** Often the best path: stabilise in Delphi first (FireDAC, SQL Server, a build that works), which makes the data shareable, then migrate processes out over time. The stabilised Delphi application becomes the fallback rather than the problem. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) reads the code and prices each path as a fixed number. ## What moving off the BDE involves The stage almost every old Delphi system needs first, whichever path follows. 1. **Inventory the data access.** Every BDE component, every alias, every Paradox or dBase table, every SQL statement. 2. **Move the tables to SQL Server** where they're still in Paradox or dBase, with the data reconciled. 3. **Replace the BDE components with FireDAC**, with tooling doing the mechanical part and a person doing the rest. 4. **Convert to Unicode** at the same time if the project predates Delphi 2009, because string handling changes anyway. 5. **Test against a copy, then run in staging** alongside the old build on the same data before switching. At the end the application looks the same to its users and no longer depends on a component deprecated two decades ago. ## Your data If it's in SQL Server already, it stays there and both old and new can share it. If it's in Paradox or dBase tables, it moves once, to SQL Server, as the first stage. Either way it never meets a change until the change has proven itself somewhere else: tested on a copy in a test environment, then run in staging with the data reconciled, before anything connects to live. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Delphi system it establishes the Delphi version, the data layer, the components and whether the project builds, then prices staying and leaving as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting The BDE, mostly. A data layer unpatched since 2002 on a network is a risk that doesn't announce itself. After that, the usual ones: a build that only works on one machine, components whose licence can't be found, and a developer pool that shrinks each year. None of them has a date. All of them get worse. ## How we approach it Stabilise the data layer first, then decide the rest on evidence. Marc Allington has worked in Delphi and in the .NET and web stacks it usually moves to, so both sides of the decision are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a Delphi takeover | Check | Why it matters | |---|---| | Delphi version, and does the project build on a current machine? | Sets the distance to a current version and whether stabilising in Delphi is realistic. | | Data access: BDE, ADO, dbExpress, FireDAC, and which tables are Paradox or dBase | The BDE is the first thing to replace; Paradox tables are the first data to move. | | Unicode or not (before or after Delphi 2009) | Decides whether string handling has to be converted, which touches most of the code. | | Third-party VCL components, versions and licences | The usual reason an old project won't compile; each needs a current version, a replacement or a rewrite. | | Where the business rules live: units, form events, stored procedures | Rules in the database are shared for free; rules in form events have to be extracted before any process moves out. | | Reports and exports | Often a separate reporting component with its own runtime and licence. | | Integrations: what calls it, what it calls | Every one is a dependency to keep working through any change. | | Source control and build | Usually a folder on one PC. The safety net comes first. | Each answer goes into the report with its consequence for staying or leaving and a fixed price for each. ## Questions Q: Is Delphi a dead language? A: No. Delphi 13 is current, Embarcadero releases regularly, and an old project can be upgraded. What's dead is the BDE underneath most old Delphi systems, and the pool of developers who'll work in Delphi is shrinking. Those two things drive the decision more than the language does. Q: Can our Delphi 7 application be upgraded to the current version? A: Usually, with work. The data layer and the string handling change, and every third-party component needs a current version or a replacement. The assessment establishes how much of that applies to yours and prices it. Q: We can't find a Delphi developer. Is that why we should leave? A: It's one of the two reasons, along with the business needing the system somewhere Delphi can't go, such as a phone. If the application does its job and can be stabilised, staying is cheaper. If nobody can be found to maintain it, stabilising it and migrating out in stages is the safer course. Q: Our data is in Paradox tables. Is that a problem? A: It's the first job. Paradox tables and the BDE go together, and both are past their end. The data moves to SQL Server, reconciled, and after that both the Delphi application and anything new can share it. Q: How long does a Delphi modernisation take? A: It depends on the version gap, the data layer and the components, which the assessment measures. The shape is the usual one: the data layer stabilised and the build working within about six weeks, then the next decision, each stage priced before you commit. --- # Windows desktop application to web URL: https://www.solvewithsoftware.com/modernise/desktop-to-web Title: Desktop Application to Web Migration Description: Desktop to web without a rewrite weekend: what carries over from WinForms, VB6 or Access, and how the desktop keeps running. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software moves Windows desktop business systems, WinForms, VB6, Access, Delphi and the like, to the web in stages: the data first, then one process at a time as a web screen, with the desktop application still running against the same database until the last screen has proven itself. The business rules and the data carry over. The desktop user interface doesn't, and it's the one part that needs redesigning rather than copying. ## Why businesses move a desktop system to the web Because the business has left the office and the system hasn't. People work from home, from vans, from sites and from customers' premises, and a system that only runs on the PCs in one building has stopped fitting how the work happens. Installing it on every laptop, keeping every copy on the same version, and getting it through a VPN are the daily costs. The other reasons arrive one at a time. A customer wants to see their own orders. A driver needs to confirm a delivery on a phone. A new starter is on a Mac. The IT company won't support the old runtime any more. Each is a reason to put one process on the web, and that's the right unit to think in. ## What carries over, and what doesn't **Carries over.** The data model, nearly always. The business rules, once they've been found: pricing, validation, status flows, the checks the office relies on. The reports, as a specification of what people need to see. Years of records. **Doesn't.** The screens. A desktop form with forty fields, a grid, six buttons and keyboard shortcuts the office has used for a decade doesn't translate to a browser, and it translates worse to a phone. The web version of that screen is designed from the process, not copied from the form. That's the part of the project that needs care and the part that pays back most, because the desktop form was usually shaped by the tool that built it rather than by the work. **Changes shape.** Printing, barcode scanners, label printers, local file access and anything that talked to hardware on the PC. All solvable on the web, all needing a decision rather than an assumption. ## The staged path 1. **Map it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) writes down what the desktop system does, which screens serve which processes, and what depends on the database besides the application. 2. **Put the data somewhere both can reach.** If it's already SQL Server, nothing moves. If it's an Access file or a local database, it moves to a server first, and the desktop application is re-pointed at it. The desktop system keeps working; it's now sharing a database. 3. **An API over the database.** A thin layer that enforces the business rules once, so the desktop application and the new web screens can't disagree about what a valid order is. 4. **One process as a web screen.** The one that most needs to leave the building: the driver's delivery confirmation, the site manager's timesheet, the customer's order history. Built, tested on a copy, run in staging alongside the desktop system on the same data, checked by the people who use it, then live. The desktop screen for that process stays available. 5. **Repeat, in order of value.** Each screen is a stage with its own fixed price. Some desktop screens may never move, because nobody needs them outside the office, and that's fine. 6. **Retire the desktop application** when the last screen that matters has moved, or keep it for the back-office jobs it still does well. No cutover weekend. No day when the old system is switched off and the new one has to work. ## Your data It stays in one place throughout, which is the point of doing the data first. Both applications read and write the same database, so there's no synchronisation and no day when two versions of the truth exist. Any move of the data itself, from a file to a server, is tested on a copy, then run in staging with counts and totals reconciled, before anything connects to live. ## Can this be done gradually? **That's the only way we do it.** The desktop application and the web application run side by side for as long as the migration takes, sharing the database. Users move one process at a time, and the ones who never leave the office may keep the desktop screens they know. Each stage is priced before you commit to it, and you can stop after any stage with a working system. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a desktop-to-web move it establishes where the data is, where the rules live, which processes need to leave the building, and what hardware the screens talk to, then prices the first stage and the rest as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks The rewrite. A desktop-to-web project that tries to rebuild every screen before going live is the one that drags on and gets cancelled. Staging it by process is the protection. The second risk is copying the desktop screens onto the web as they are. It feels safe because the office knows them, and it produces a web application that's worse than the desktop one on a laptop and unusable on a phone. Designing from the process is more work up front and the only version that pays back. ## How we approach it Data first, rules once, screens by process. Marc Allington has built desktop and client-server business systems and web applications and has moved work between the two, so the trade-offs are familiar. Everything we build runs on open, widely used technology, React and Node or .NET over SQL Server or PostgreSQL, in your own accounts, with full source code and ownership transferring to you on final payment. ## What the assessment establishes for a desktop-to-web move | Question | Why it matters | |---|---| | Where is the data: SQL Server, an Access file, a local database on one PC? | Decides whether stage two is nothing, a move, or a rescue. | | Where do the business rules live: database, application code, or people's heads? | Rules in the database are shared for free. Rules in the code have to be found and moved into the API. | | Which processes need to leave the building, and who does them? | Sets the order of the stages and which screens go first. | | What does the application talk to on the PC: printers, scanners, files, other programs? | Each one is a design decision on the web, and a surprise if found late. | | How do users log in today, and who is allowed to see what? | Desktop systems often assume anyone at the PC is trusted. The web can't. | | Which reports and exports exist, and who depends on them? | The part most often left until last and noticed first. | | Can the desktop application be built and run in a test environment? | If not, that's stage one, before anything else. | Each answer goes into the report with a consequence for the staged path and a fixed price for the first stage. ## Questions Q: Do we have to give up the desktop application? A: No. It keeps running against the same database for as long as the migration takes, and for the office jobs it does well, it can stay for good. The web screens are for the processes that need to leave the building. Q: Can the web version look the same as the desktop one? A: It can, and it shouldn't. A desktop form copied onto the web is worse on a laptop and unusable on a phone. The web screen is designed from the process the form serves. Q: We print labels and scan barcodes. Does that work on the web? A: Yes, with the right decisions. Barcode scanners that act as keyboards work in a browser as they are. Label and receipt printing, and anything that reads local files, needs a small helper or a modern printer that talks to the network. The assessment lists each device and how it's handled. Q: Our vans lose signal. Can a web app work offline? A: For the processes that need it, yes. A web app can hold the driver's day on the phone and sync when signal returns. It's a design requirement rather than an afterthought, so it's decided per process in the assessment. Q: How long does moving to the web take? A: It depends on how many processes need to move, which the assessment counts. What we can say is the shape: the data and a first web screen within about six weeks, then one process at a time, each priced before you commit. --- # DNN (DotNetNuke) modernisation URL: https://www.solvewithsoftware.com/modernise/dnn Title: DNN (DotNetNuke) Modernisation Description: DotNetNuke on DNN 5 to 9 and .NET Framework, which DNN never left. Upgrade in place, or move the modules to technology you own. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over DNN sites that became business systems: the customer portal, the intranet, the members' area, with custom modules nobody can change. DNN Platform is still maintained, with 10.3 released in 2026, but it runs on .NET Framework 4.8 and has never moved to modern .NET, and old sites are usually several major versions and a set of abandoned third-party modules behind. We read the site, upgrade it in place where the modules survive, and move the application parts out to technology you own where they don't, in stages, on a fixed price from the assessment. ## Where DNN stands Alive, and standing still. DNN Platform is open source under the .NET Foundation and gets releases; 10.3.2 came out in May 2026. The commercial Evoq editions continue too. But every version of it targets .NET Framework 4.8, there is no DNN on modern .NET, and the Web Forms (https://www.solvewithsoftware.com/modernise/aspnet-web-forms) technology most modules are built on was never carried forward by Microsoft either. The sites we see are older than that. DNN 5, 6 or 7 on a Windows server that's out of support, with third-party modules from vendors who've closed, custom modules written by someone who's left, and a skin that breaks on phones. Upgrading DNN itself is possible, in steps, and each step is a chance for a module to stop working. ## What a DNN site is made of - **The platform**: pages, users, roles, permissions, content, all in SQL Server. - **Third-party modules**: forms, galleries, e-commerce, document libraries, bought years ago, some from vendors who no longer exist. - **Custom modules**: the application. The quote calculator, the booking system, the members' database, written as Web Forms controls against a specific DNN version. - **The skin**: the design, usually HTML from the year it was built. - **Integrations**: the module that talks to the CRM or the accounts system. The platform and the content are the easy part. The custom modules are where the business runs and where the modernisation is decided. ## Upgrade in place, or move the application out? **Upgrade in place** when the site is mostly content and the custom modules are small. DNN upgrades version by version, the content comes with it, and modules are fixed or replaced as they break. The site ends on DNN 10 and .NET Framework 4.8, which is supported for as long as the Windows version it ships with, and no further. **Move the application out** when the custom modules are the business. They're rebuilt as a modern .NET or web application with its own database, one module at a time, with DNN still serving the pages that haven't moved. The content either stays on an upgraded DNN, or moves to a current CMS, or, often, turns out to be a handful of pages that don't need a CMS at all. **Usually both.** Upgrade DNN enough to be safe, then take the application out. The assessment reads every module and says which. ## The staged path 1. **Inventory.** Every module, its version, its vendor, whether the source exists, and which pages use it. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) produces this from the site and the database. 2. **Safety net.** Source control for the custom modules, a copy of the site running in a test environment, and a backup that's been restored. 3. **Upgrade the platform** in steps, fixing or retiring modules as each step breaks them, until it's on a supported Windows server and a current DNN. 4. **Rebuild the application modules** that matter, one at a time, as a modern application alongside, with users re-pointed as each one moves. 5. **Decide the content**: upgraded DNN, a current CMS, or plain pages. 6. **Retire what's left** when the last module has moved. Each stage has its own fixed price, and each ends with something safer than before. ## Your data It's in SQL Server, in DNN's schema and in each module's own tables. Users, roles and content export cleanly; module data is mapped table by table. Nothing meets a change until the change has proven itself somewhere else: a migration tested against a copy in a test environment, then run in staging with counts reconciled, before anything switches. ## Can this be done gradually? **Yes. Platform upgrades go one version at a time.** Application modules move one at a time behind the same site, so users see one change at a time rather than a new system. Stop after any stage and keep everything. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a DNN site it produces the module inventory, tests whether the site can be upgraded, identifies which modules are the application, and prices the stages as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting An old DNN site is usually public-facing, usually on an unsupported Windows server, and usually several versions behind on a platform that publishes its security fixes. The third-party modules get no fixes at all. And the custom modules are on Web Forms, a technology with no future version, so every year makes the rebuild larger rather than smaller. ## How we approach it Inventory, safety net, upgrade what upgrades, move the application out. Marc Allington has built on .NET Framework and Web Forms, which is what DNN and its modules are made of, and builds on modern .NET and the web stack they move to. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a DNN site | Check | Why it matters | |---|---| | DNN version, .NET Framework version, Windows Server version | Sets the urgency and the number of upgrade steps. | | Every installed module, its version, vendor and whether the vendor still exists | The abandoned ones break on upgrade and have to be replaced or retired. | | Custom modules: source available, which DNN APIs they use, Web Forms or MVC | Decides upgrade-in-place versus rebuild, module by module. | | Which pages use which modules, and traffic per page | Tells us which modules matter and which are dead weight. | | Users, roles and permissions, and how people log in | Carries across to whatever the application becomes. | | Module data tables, and what depends on them | The mapping for the rebuild. | | Integrations: CRM, accounts, payment, email | Every one has a caller to re-point. | | Backups, source control, a test copy of the site | Usually none. The safety net comes first. | Each answer goes into the report with its stage, its consequence and a fixed price. ## Questions Q: Is DNN dead? A: No. DNN Platform is open source under the .NET Foundation and released 10.3.2 in May 2026. It's stuck rather than dead: every version runs on .NET Framework 4.8 and there's no version on modern .NET, so it has a ceiling. Q: Can an old DNN 5 or 6 site be upgraded to DNN 10? A: Usually, in steps, and with modules breaking along the way. Whether it's worth it depends on how much of the site is content and how much is custom modules. The assessment tests the upgrade on a copy before anyone commits to it. Q: Our custom modules were written by someone who's left. Can you change them? A: If the source exists, yes; they're Web Forms controls in C# or VB.NET. If only the compiled module exists, it can be read well enough to rebuild from, and rebuilding is usually the plan for the modules that matter anyway. Q: Should we replace DNN with another CMS? A: Only if the content needs a CMS. Often the application modules are the reason the site exists and the content is a handful of pages. The assessment separates the two and treats them differently. Q: How long does a DNN modernisation take? A: It depends on how many modules there are and how many are the application, which the assessment counts. The shape is the usual one: safe and building first, something moved within about six weeks, then one module at a time, each priced before you commit. --- # .NET Core and early .NET upgrades URL: https://www.solvewithsoftware.com/modernise/dotnet-core Title: .NET Core Upgrade to .NET 10 Description: .NET Core 2.1 to .NET 7 are out of support, .NET 8 follows in November 2026. We get it building, then step it to .NET 10 in place. From £395 + VAT. Last reviewed: 2026-09-04 An application on .NET Core 2.1 or 3.1, or on .NET 5, 6 or 7, runs on a version Microsoft no longer patches, and .NET 8 and 9 join them on 10 November 2026. It's the same platform as .NET 10, so the upgrade is done in place, one version step at a time, with the breaking changes at each step fixed as they appear. Solve With Software takes over the code, gets it building on a current machine, moves it to .NET 10 and modernises what the upgrade exposes, on a fixed price from the assessment. ## Where the versions stand Microsoft ships a new .NET every November. Even-numbered releases are long-term support and get three years; odd-numbered ones get two. An application built by a contractor in 2019 or 2021 is usually on whichever version was current that month, and nobody has moved it since. | Version | Support ended, or ends | |---|---| | .NET Core 2.1 | August 2021 | | .NET Core 2.2 | December 2019 | | .NET Core 3.1 | December 2022 | | .NET 5 | May 2022 | | .NET 6 | November 2024 | | .NET 7 | May 2024 | | .NET 8 | 10 November 2026 | | .NET 9 | 10 November 2026 | | .NET 10 (current, LTS) | November 2028 | Finding out which you're on takes a minute: the \ ## Why this is a different job from .NET Framework .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) applications are stuck because Web Forms and WCF were never carried forward, so parts of them have to be rebuilt. Nothing like that applies here. .NET Core 3.1, .NET 6 and .NET 10 are the same platform at different ages. ASP.NET Core MVC, Razor Pages, Web API, Blazor, worker services and Entity Framework Core all exist on .NET 10 in recognisable form. So the upgrade is a change of target framework, a round of package updates, and a list of breaking changes to work through, one version step at a time. What takes the time is the list: what changed between the version you're on and the version you're going to, and what in your code touched it. ## What breaks at each step The recurring ones, from applications we've moved: - **2.x to 3.x.** The hosting model changed and endpoint routing arrived. Newtonsoft.Json stopped being the default serialiser in favour of System.Text.Json, which handles dates, enums and case differently. Entity Framework Core 3 stopped silently running parts of a query in memory, so queries that used to work started throwing. - **3.1 to 6.** Mostly smooth. Nullable reference types and the minimal hosting model are optional and worth adopting. Packages that stopped at 3.1 need replacing. - **6 to 8 and 10.** The application code barely notices. The packages do. IdentityServer4, which a lot of applications of the era used for login, ended support in November 2022 and its successor is commercially licensed. MediatR and AutoMapper moved to commercial licences in 2025, free below a team-size threshold. Each is a decision: pay, replace, or in the case of login, move to ASP.NET Core Identity. - **Anywhere.** Windows-only APIs that need a flag or a replacement if the target is Linux. An EF Core migration history that nobody has run from the start. A build that only ever worked on the contractor's machine because the SDK version was never pinned. None of these is a rewrite. Each is a known change with a known fix, and the assessment lists which ones apply before the price is set. ## The staged path 1. **Get it building.** The right SDK pinned in a global.json, packages restoring, the solution compiling on a clean machine. This is where an unpinned SDK or a package that has vanished from NuGet shows up. 2. **Safety net.** Source control, a test environment, a staging environment, and tests around the processes that matter, before any version changes. 3. **Step the version.** One long-term release at a time for an old application (3.1 to 6, 6 to 8, 8 to 10), or straight to 10 for a small one. Fix the breaking changes at each step, run the tests, move on. 4. **Replace what stopped.** The packages that ended at an old version, the login library, the licences that changed. 5. **Test the data layer.** EF Core generates different SQL after an upgrade. Queries run against a copy, then in staging against the live schema. 6. **Deploy to hosting you own.** The IIS hosting bundle on a current Windows Server, or Linux, or a container, decided on cost and what else you run. Each stage has its own fixed price, and each ends with the application running on a supported version. ## Your data Usually SQL Server or PostgreSQL, and it stays where it is. The upgrade changes the code that talks to it, so the data layer never meets a change until the change has proven itself somewhere else: tested against a copy in a test environment, then run in staging against the live schema with results reconciled, before anything connects to live. ## Can this be done gradually? **Yes. A single web application upgrades in version steps, each of which leaves it running and can be deployed on its own.** A system made of several services moves one service at a time, with the rest untouched until their turn. Where a solution mixes .NET Framework and .NET Core projects, the Framework page covers the other half and the two plans run together. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a .NET Core application it reads every project file and package reference, confirms whether the solution builds, lists the breaking changes between your version and .NET 10, and prices the steps as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting The date, first: .NET 8 and .NET 9 both end on 10 November 2026, so an application that felt current in 2024 is about to be unpatched. Then the compounding. Every version skipped adds a step and a set of breaking changes to the eventual upgrade, and each year more packages drop the old target frameworks. And an unpatched web application facing the internet is the one part of the estate an insurer or a customer's security questionnaire will ask about. ## How we approach it Get it building, put the safety net under it, step the version, replace what stopped, test the data layer. Marc Allington builds on modern .NET now and has taken applications through these version steps, so the breaking changes are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a .NET Core application | Check | Why it matters | |---|---| | Target framework of every project, and whether the solution builds on a clean machine | Sets the number of version steps. If it doesn't build, that's stage one. | | Application types: MVC, Razor Pages, Web API, Blazor, worker services, console | All carry forward; the mix decides where the breaking changes land. | | Package references, and which ended at an old version or changed licence | The dead and the newly commercial packages are where the decisions are. | | Login: ASP.NET Core Identity, IdentityServer4, an external provider | IdentityServer4 is unsupported since 2022; its replacement is a decision, not a package bump. | | Data access: EF Core version, migrations history, raw SQL | EF Core changes its generated SQL between versions; the migrations have to run from scratch in test. | | Serialisation: Newtonsoft.Json or System.Text.Json, and which behaviours the code relies on | The most common source of subtle breakage across 2.x to 3.x. | | Hosting: IIS, Windows service, Linux, container, and which Windows Server | Sets the deployment target and whether Windows-only APIs matter. | | Tests, source control, build pipeline, pinned SDK | The safety net comes before any version step. | Each answer goes into the report with its step, its consequence and a fixed price. ## Questions Q: Is .NET 8 still supported? A: Until 10 November 2026. .NET 9 ends the same day, because Microsoft extended its short-term releases to two years. .NET 10 is the long-term release to be on, supported to November 2028. Q: Should we go straight to .NET 10 or one version at a time? A: Small application, straight to 10. Larger or older application, one long-term release at a time, because each step has its own breaking changes and it's easier to find which one broke a behaviour when only one has changed. The assessment says which applies. Q: Is this a rewrite, like .NET Framework? A: No. .NET Core and .NET 10 are the same platform, so MVC, Razor Pages, Web API, Blazor and EF Core all carry forward. The work is package updates and breaking changes, not rebuilding pages. A solution that also has .NET Framework projects has its own page. Q: We're on .NET Core 2.2. Is that worse? A: Older, and unsupported since December 2019, so more steps and the 2.x to 3.x changes to work through first. The path is the same shape: get it building, safety net, then step the versions. Q: How long does a .NET Core upgrade take? A: It depends on how many version steps there are and which packages stopped along the way, which the assessment counts. The shape is the usual one: the application running on a supported version within about six weeks, then each further step priced before you commit. --- # .NET Framework modernisation URL: https://www.solvewithsoftware.com/modernise/dotnet-framework Title: .NET Framework Modernisation Description: .NET Framework 4.x: WinForms, WPF, Web Forms, WCF. What upgrades in place to modern .NET, what needs replacing, done in stages. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software modernises C# applications built on .NET Framework 2.0 to 4.8, moving them to modern .NET in stages. WinForms, WPF, class libraries and most services upgrade in place. ASP.NET Web Forms and WCF don't, and need a planned replacement, usually one page or one service at a time alongside the old one. The assessment reads the solution and tells you which of those you have, with a fixed price on each step. ## Where .NET Framework stands There's no switch-off date, which is why so much of it is still running. .NET Framework 4.8 ships as part of Windows and is supported for as long as the Windows version it came with, so an application on it isn't unsupported in the way a VB6 IDE is. What's stopped is everything moving forward. New libraries target modern .NET only. Security fixes for the packages an old application depends on stop arriving. Hosting on anything but a Windows server is out. And the developers who'd take on a Framework codebase are the same developers who'd rather not. The application runs; the business around it can't move it. An application already on .NET Core, or on .NET 5 to 8, is a smaller job with its own page (https://www.solvewithsoftware.com/modernise/dotnet-core). The date that does apply is the operating system's. Windows Server 2016 support ends in January 2027, and a .NET Framework application on it goes out of support with the server. ## What upgrades in place, and what doesn't This is the question the assessment answers first, because it decides the shape of the whole project. **Upgrades in place, with work but no rewrite.** - Class libraries and console applications. Usually the easiest. - WinForms and WPF desktop applications. Both exist on modern .NET; the migration is mostly package updates and API differences, and the screens survive. - ASP.NET MVC and Web API. Different enough to be a port rather than an upgrade, but the controllers and views mostly carry across. - Entity Framework 6 to EF Core. A real piece of work, and worth it: the data access layer is where a lot of the technical debt sits. **Doesn't upgrade. Needs a replacement.** - ASP.NET Web Forms (https://www.solvewithsoftware.com/modernise/aspnet-web-forms). There is no Web Forms on modern .NET. Each page has to be rebuilt, usually in Razor Pages or Blazor, and the sensible way is one page at a time behind a proxy, with the old site still serving the rest. - WCF services. The server side has a community port (CoreWCF) that can be a bridge, but the long-term answer is REST or gRPC, one service at a time. - Anything built on Windows Workflow, Remoting or other frameworks that were never carried forward. A typical application has some of each, which is why the plan is staged rather than a single upgrade. ## The staged path 1. **Map the solution.** Every project, its target framework, its package references, and which of them are dead. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) produces this as a dependency map. 2. **Safety net first.** Source control, a build that works on a current machine, a test environment, and tests around the processes that matter. Framework applications built years ago often have none of these. 3. **Upgrade the libraries.** Move shared code to .NET Standard or modern .NET so both the old and new applications can use it. This is the stage that makes everything after it possible. 4. **Upgrade what upgrades.** Desktop applications and services that have a direct path move across, one at a time, each tested in staging against the live database before switching. 5. **Replace what doesn't, alongside.** Web Forms pages rebuilt one at a time behind a reverse proxy, so the old site and the new one look like one application to users. WCF services replaced one at a time with the callers re-pointed. 6. **Retire the old hosting** when the last piece has moved. Each stage has its own fixed price, and each ends with working software you've already paid for. ## Your data Usually SQL Server, and usually it stays exactly where it is. Modern .NET talks to the same database, so old and new applications share it throughout the migration and there's no data move at all. Where EF6 moves to EF Core, the generated queries change and are tested on a copy, then in staging against the live schema, before anything connects to live. ## Can this be done gradually? **Yes, and for a mixed solution it's the only safe way.** Libraries first, then whichever application carries the most risk or the most value, then the rest in order. Web Forms and WCF replacements run alongside the old code behind a proxy, so users never see a cutover. Stop after any stage and keep everything. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a .NET Framework solution it maps every project and package, tests whether the thing builds, identifies what upgrades in place and what doesn't, and prices the stages as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting The server date, first: January 2027 for Windows Server 2016. Then the slow ones. Each year the gap between .NET Framework and modern .NET widens, more packages drop Framework support, and the upgrade gets harder rather than easier. And the developer who knows the solution is a single point of failure for as long as it's on a platform nobody new wants to learn. ## How we approach it Map it, make it safe, upgrade what upgrades, replace what doesn't, one piece at a time. Marc Allington has built on .NET Framework for years and builds on modern .NET now, so both sides of the migration are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a .NET Framework solution | Check | Why it matters | |---|---| | Target framework of every project, and does the solution build on a current machine? | If it doesn't build, that's stage one. Old Framework versions (2.0, 3.5) add a step. | | Application types: WinForms, WPF, Web Forms, MVC, Web API, WCF, Windows services, console | Sorts every project into upgrade-in-place or replace-alongside. | | Package references, and which are unmaintained or Framework-only | The dead packages are where the surprises are; each needs a replacement or a decision. | | Data access: EF6, raw ADO.NET, an ORM that no longer exists? | EF6 to EF Core is a project in its own right and the most valuable one. | | Third-party controls and licences (grids, reporting, PDF) | Old commercial controls often have no modern .NET version; the licence may not even be findable. | | Hosting: IIS on which Windows Server, and what else runs there? | Sets the date pressure and whether the target is a modern server, a container or the cloud. | | Tests, source control, build process | Usually thin or absent. The safety net comes before any upgrade. | | Integrations: what calls it, what it calls | Every WCF endpoint has a caller that has to be re-pointed. | Each answer goes into the report with its stage, its consequence and a fixed price. ## Questions Q: Is .NET Framework unsupported? A: Not yet, and not on a fixed date. Framework 4.8 is supported with the Windows version it ships on. The pressure comes from the ecosystem, which has moved to modern .NET, and from the server it runs on: Windows Server 2016 support ends in January 2027. Q: Our application is ASP.NET Web Forms. Can it be upgraded? A: Not in place; Web Forms doesn't exist on modern .NET. It's replaced one page at a time, usually in Razor Pages or Blazor, behind a proxy so the old site keeps serving the pages that haven't moved. The data layer and the business logic underneath often can be upgraded and shared. Q: We have WCF services. What happens to them? A: Two options. CoreWCF lets the server side run on modern .NET as a bridge, which buys time. The long-term answer is REST or gRPC, one service at a time, with each caller re-pointed as its service moves. Q: It's VB.NET rather than C#. Does that change anything? A: Not much. VB.NET runs on modern .NET for WinForms, WPF and libraries. The web side has fewer options, so a VB.NET Web Forms application usually ends up in C# when its pages are rebuilt. Q: How long does a .NET Framework migration take? A: It depends on how many projects there are and how many of them are Web Forms or WCF, which the assessment counts. The shape is the same for all of them: safety net and libraries first, something upgraded and running within about six weeks, then one piece at a time, each priced before you commit. --- # The spreadsheet that runs everything URL: https://www.solvewithsoftware.com/modernise/excel-to-system Title: Replace Excel With a Proper System Description: The spreadsheet that runs everything: shared, macro-laden, one person understands it. Made into a system, its rules kept. From £395 + VAT. Last reviewed: 2026-09-04 A spreadsheet becomes a business system by accident, one column at a time, until thirty people depend on it, two can't open it at once, and one person understands the macros. Solve With Software treats that spreadsheet as a specification: the columns are the data model, the formulas and macros are the rules, and the tabs are the processes. The system that replaces it is built one process at a time, with the spreadsheet kept alongside until each one has moved, and Excel kept for what it's good at. ## How a spreadsheet becomes the system Nobody decides it. Someone builds a sheet to track quotes. It gets a second tab for orders. A lookup to the price list. A macro to produce the invoice. A shared drive so the office can use it. Ten years on, it has forty tabs, twelve thousand rows, formulas that reach across sheets in ways nobody can follow, and a copy on every laptop that has drifted from the one on the server. That's not a failure of anyone. Excel is the best tool in the world for a person who knows what they need and needs it today. The trouble is that it was never a system, and the business started treating it as one. ## When it has stopped being a spreadsheet - Two people can't work in it at once, or one of them loses their changes when they can. - There are several copies, and they disagree. - It's slow to open, slow to recalculate, and corrupts now and then. - The macros were written by someone who has left, and nobody dares press the button they don't understand. - Numbers get retyped from it into another system, and the two never quite match. - There's no history: a cell was changed last Tuesday, and nobody knows what it said before. - The auditors, the bank or a customer have asked how the business controls it, and the answer was a shrug. ## What the spreadsheet already knows Everything a new system needs, in a form that's easier to read than most code. - **The data model.** Every column is a field. Every tab is a table, or a process. The lookups are the relationships. - **The rules.** Every formula is a business rule written down. The pricing calculation, the VAT handling, the discount that applies to one customer type, the date maths that decides what's overdue. - **The processes.** The macros, and the manual steps around them, describe what the business does in what order. - **The data.** Years of it, ready to migrate. Reading a spreadsheet as a specification is most of the work, and it's work that has to be done by a person sitting with the person who built it. ## What replaces it A database the business owns, with the rules in one place and enforced, and screens designed from the processes rather than copied from the grid. Multiple people at once, a history of every change, one version of the truth, and reports that come out of the data instead of being assembled by hand. Excel doesn't disappear. It stays for what it's good at: ad-hoc analysis, what-if, the finance director's own models, and it reads from the new system's data instead of being the place the data lives. That distinction, the system as the record and Excel as the lens, is the one that makes the change stick. ## The staged path 1. **Read it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) sits with the person who built the spreadsheet and maps every tab, column, formula and macro into a system description with the rules made explicit. Where two copies disagree, the differences are listed rather than guessed. 2. **Migrate the data**, cleaned. Duplicates resolved, free-text columns turned into proper values, dates stored as text made into dates. Reconciled against the spreadsheet's totals. 3. **Build the first process**, the one that hurts most: usually the one where two people collide or where numbers get retyped. Run it in staging on the migrated data, checked by the people who use it, then live. The spreadsheet keeps running everything else. 4. **Repeat, process by process**, until the spreadsheet is a report rather than a record. 5. **Point Excel at the system** for the analysis people still want to do there. Each stage is priced before you commit; stop after any stage and keep everything. ## Your data It comes out of the spreadsheet once, cleaned, and it never meets a change until the change has proven itself somewhere else. The migration is tested on a copy in a test environment, then run in staging with every total reconciled against the spreadsheet, before anything connects to live. The spreadsheet stays as the fallback until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a spreadsheet system it maps the tabs, formulas and macros, tests how the data comes out, and prices the first process as a fixed number. Spreadsheet systems are often small in scope and quick to improve, which makes them a good first project. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it The spreadsheet is the specification and the person who built it is the expert. Marc Allington has turned enough spreadsheets into systems to know that the formulas are worth more than they look and the macros less. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## How we read a spreadsheet as a specification The method, step by step: 1. **Inventory the tabs.** Which are data, which are processes, which are reports, and which are dead. 2. **Map the columns.** Every column becomes a field with a type and, where it's a lookup, a relationship. 3. **Extract the formulas.** Every formula becomes a rule, written in plain English, with the person who built it confirming what it's for. 4. **Read the macros.** What each button does, in order, and what a person does around it. 5. **Find the copies.** Every version in circulation, and where they differ. 6. **Reconcile the data.** Totals and counts from the spreadsheet become the acceptance test for the migration. 7. **Sequence the processes.** Which one first, from where the pain is. The output is a system description a developer can build from, and it's section two of the assessment report, whoever builds it. ## Questions Q: Do we have to stop using Excel? A: No. Excel stays for what it's good at, analysis and modelling, and reads from the new system's data. What changes is where the record lives. The system becomes the truth; Excel becomes the lens. Q: Our spreadsheet has a lot of macros. Do those carry over? A: As rules, yes; as code, no. Each macro is read for what it does and rebuilt properly in the system, usually more simply, because most macros exist to work around something a database does natively. Q: It's just one spreadsheet. Is that worth a project? A: Often more so than a big system. One spreadsheet with a clear job is a small, contained first project that improves things quickly for the people using it. It's also the kind of work we price as a single fixed stage. Q: Wouldn't an off-the-shelf product do? A: Sometimes, and the assessment will say so. If the spreadsheet is doing something a standard product does well, buying it is the right answer and the data still needs migrating. If the spreadsheet encodes how your business is different, that's what a bespoke system is for. Q: How long does it take? A: It depends on how many processes the spreadsheet runs, which the assessment counts. The shape is the usual one: the data migrated and the first process live within about six weeks, then one at a time, each priced before you commit. --- # FoxPro migration URL: https://www.solvewithsoftware.com/modernise/foxpro Title: FoxPro Migration and Replacement Description: FoxPro lost support in 2015 and is 32-bit only. The DBF data moves cleanly. We rebuild alongside it, one process at a time. From £395 + VAT. Last reviewed: 2026-09-04 Visual FoxPro has been out of support since January 2015, runs on Windows 11 only through the 32-bit compatibility layer, and its database drivers can't talk to modern 64-bit applications. The data in its DBF tables is the asset, and it moves to SQL Server cleanly without FoxPro installed. Solve With Software takes a FoxPro system over by getting the data out first, then rebuilding the processes one at a time alongside the running application, which stays as the fallback until the last one has moved. ## Where FoxPro stands Out of support for over a decade. Microsoft ended extended support for Visual FoxPro 9 in January 2015 and there was never a version 10. It's a 32-bit product, so on Windows 11 it runs through the compatibility layer, and its ODBC and OLE DB drivers are 32-bit only, which is why a modern 64-bit application can't read a FoxPro database directly. And yet plenty of businesses run on it every day, because the systems were built well by people who knew the business, and DBF files don't stop working. The risk isn't that it fails tomorrow. It's that nothing around it can be changed, nothing new can talk to it, and the person who understands it is retiring. ## What we usually find inside A data-centric system, which is the FoxPro way. Tables in DBF files with their indexes alongside, memo fields holding notes and documents, programs and forms that do the work close to the data, and a set of reports the business has relied on for years. The data model is usually clear, because FoxPro developers thought in tables. The rules are in the program files and the form events, readable but spread out. Code pages and date handling need care. And there's often a second FoxPro system somewhere that nobody mentioned. ## The paths **Contain it.** Make sure the runtime is installed and working on a supported machine, the DBF files are backed up and the backup restores, and the build is documented. This is the first stage whatever follows, and for a small system with a few users it can hold for a while. **Move the data, keep the front end.** DBF tables move to SQL Server, reconciled, and the FoxPro application is pointed at SQL Server through its remote data features. The 32-bit driver problem goes away for everything else: modern applications, reporting tools and integrations can now read the data. The FoxPro screens carry on. This is often the biggest single improvement for the least work. **Rebuild alongside.** With the data on SQL Server, new processes are built on the web or on .NET one at a time, sharing the database, while FoxPro keeps running everything that hasn't moved. Each process switches when it has proven itself, and FoxPro is retired when the last one has. **Replace with a package.** Sometimes the right answer, when an off-the-shelf product now does what the FoxPro system was built to do. The data still has to move, and the assessment says whether the fit is real. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) reads the tables and the programs and prices each path as a fixed number. ## Getting the data out Cleaner than most legacy migrations, because the DBF format is well understood and the tools are standard. The tables are read through ODBC, OLE DB or a dedicated DBF reader, moved into SQL Server with the types mapped properly (dates, logicals, memos, the code page), and reconciled: record counts, totals, and a sample compared row by row. The things that need a person rather than a tool: memo fields that hold structured data nobody documented, indexes that encode rules, deleted-but-not-packed records, and the second system that shares tables with the first. ## Your data It moves once, to SQL Server, and it never meets a change until the change has proven itself somewhere else. The migration is tested against a copy in a test environment, then run in staging with every table reconciled, before anything connects to live. The DBF files stay untouched as the fallback until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a FoxPro system it reads the tables and the programs, tests how the data comes out, and prices containment, the data move and the rebuild as fixed numbers. The data move is usually the first stage and the one with the most immediate benefit. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting A 32-bit runtime on an operating system that's moving on, with no vendor patches since 2015. A driver that modern software can't use, so every new tool the business buys has to be worked around. DBF files that corrupt under network load, like Access files do, and a backup nobody has tested. And the developer, who is one person, and who is retiring. ## How we approach it Data first, because it's the asset and because moving it fixes the most. Marc Allington has worked in FoxPro and in the SQL Server, .NET and web stacks it moves to. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a FoxPro takeover | Check | Why it matters | |---|---| | Version: FoxPro 2.x, Visual FoxPro 6 to 9 | Sets the runtime, the driver and how the programs are structured. | | Do the source programs exist, or only the compiled application? | Without source, the rules are read from behaviour and data, which is slower. | | Table inventory: DBF files, indexes, memo files, and which programs use which | The data model, and the first thing to move. | | Code page and date handling | Where migrations lose accented characters and shift dates by a day. | | Reports and their tooling | Often a separate component; the finance team notices first. | | Who reads the tables besides FoxPro | Spreadsheets, other systems, scheduled exports, all through the 32-bit driver. | | Runtime and machines: where it runs, and does it run on a supported OS? | Sets the containment steps and the urgency. | | Backup: is there one, and does it restore? | Tried, not assumed. | Each answer goes into the report with its consequence for each path and a fixed price. ## Questions Q: Will our FoxPro system keep running on Windows 11? A: Usually, yes, through the 32-bit compatibility layer, and with no patches since 2015. What tends to break is anything around it that needs the driver: a new reporting tool, an integration, a 64-bit application. That's what moving the data fixes. Q: Can we keep the FoxPro screens and just move the data? A: Yes, and it's often the first stage. The DBF tables move to SQL Server and the FoxPro application reads them from there. Everything else can then reach the data, and the screens carry on until you decide to replace them. Q: We only have the compiled program, not the source. What then? A: The data still moves, because the tables are readable without the source. The rules are read from how the program behaves and from the people who use it. It's slower, and the assessment plans for it. Q: Should we just buy a package instead? A: Sometimes. If an off-the-shelf product now does what the FoxPro system was built for, the assessment will say so. The data still has to move and be reconciled either way, so that stage is the same. Q: How long does a FoxPro migration take? A: It depends on how many tables and programs there are, which the assessment counts. The shape is the usual one: the data on SQL Server and reconciled within about six weeks, then processes one at a time, each priced before you commit. --- # Ionic app modernisation URL: https://www.solvewithsoftware.com/modernise/ionic Title: Ionic App Modernisation Description: Ionic 1 to 3 apps sit on AngularJS and Cordova, both past their end. The web code carries over, the shell moves to Capacitor. From £395 + VAT. Last reviewed: 2026-09-04 An Ionic app is a web application in a native shell, which is good news for a takeover: the screens and the logic are web code that carries over. What ages is the shell and the framework underneath. Ionic 1 to 3 apps sit on AngularJS or early Angular over Cordova, both out of support, and Ionic's own commercial services are being wound down after its acquisition by OutSystems, with Appflow closing at the end of 2027. Solve With Software brings the framework current, moves the shell from Cordova to Capacitor, and gets the app shipping through the stores again, in stages, on a fixed price from the assessment. ## Where Ionic stands Split. The open-source parts, Ionic Framework and Capacitor, are alive and maintained, with Ionic 8 current. The commercial parts are not: Ionic stopped selling Appflow, Identity Vault and Portals in February 2025, is winding them down, and closes Appflow on 31 December 2027. If your app's builds go through Appflow, that's a date. Old Ionic apps have older problems. Ionic 1 is AngularJS, which ended in 2021. Ionic 2 and 3 are early Angular, several majors behind. All three usually run on Cordova, which is open source, maintained by a shrinking community, and whose plugins are the first thing to break when the stores raise their targets. Since April 2026 the App Store requires Xcode 26 builds; from August 2026 Google Play requires updates to target Android 16. An old Cordova plugin often can't meet either. ## What carries over More than with most mobile stacks, because the app is a web app. The screens, the logic and the data handling are HTML, CSS and TypeScript or JavaScript, and they survive a framework upgrade largely intact. The backend is wherever it was. The design is yours. What doesn't carry over is the shell (Cordova to Capacitor is a migration, not an upgrade), the framework version (AngularJS to modern Angular is a rewrite of the components; Angular N to N+3 is a series of upgrades), and any plugin that has no Capacitor equivalent. ## The paths **Upgrade in stages.** Angular major by major with the official tooling, Ionic to 8, Cordova to Capacitor with each plugin replaced or rewritten, the whole thing building and shipping to a test group after each step. The right path for Ionic 4 onwards, and for Ionic 3 apps whose Angular is upgradeable. **Rebuild the components, keep the logic.** For Ionic 1 (AngularJS), the components are rebuilt in modern Angular (or React or Vue, if the team prefers) one screen at a time, with the services and the data handling carried across. Capacitor from the start. **Rebuild in Flutter.** When the app is small, or when the web-in-a-shell approach was the wrong fit for what it does (heavy maps, camera, offline). The backend and the design carry across. We build in Flutter, so the assessment compares it on cost rather than preference. **Get off Appflow**, whichever path: builds move to a pipeline you own before the end of 2027. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) reads the app and prices each path as a fixed number. ## The accounts and keys you need to own The same list as any mobile app, plus Appflow. Apple Developer account, certificates and profiles. Google Play account, upload key, and whether Play App Signing holds the signing key. The backend account. Push certificates. And the Appflow account, whose build configuration has to be reproduced somewhere else before it closes. The assessment produces the list and the first stage works through it. ## Your data Behind an API or in a hosted backend, and it stays where it is, in an account you own. Nothing reaches your users until it has proven itself somewhere else: a build tested against a staging backend, released to a test group through TestFlight and the Play internal track, then to the store. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an Ionic app it establishes the Ionic and Angular versions, the Cordova plugins and their Capacitor equivalents, the accounts, and whether it builds, then prices the upgrade and the rebuild as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting The store dates that have already passed, which an old Cordova plugin can't meet. Appflow closing at the end of 2027 if your builds depend on it. An AngularJS core with no fixes since 2021 on an app that talks to your backend. And the plugin that breaks on the next phone operating system update, with no way to ship a fix. ## How we approach it Keys and accounts first, then a build, then the shell, then the framework, in stages. Marc Allington builds mobile apps in Flutter and web applications in Angular, which are the two things an Ionic app is made of. Everything we build runs in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for an Ionic takeover | Check | Why it matters | |---|---| | Ionic version, and the framework under it: AngularJS, Angular N, React, Vue | Ionic 1 means a component rewrite; later versions upgrade. | | Cordova or Capacitor, and the plugin list | Each Cordova plugin needs a Capacitor equivalent or a rewrite; the abandoned ones are the cost. | | Does it build, for both platforms, on a clean machine? | The first failure tells you what the handover missed. | | Appflow: is it used for builds or live updates? | A closing date at the end of 2027 and a pipeline to reproduce. | | Apple and Google accounts, keys, Play App Signing | Without them no build ships. | | Backend, push, analytics, third-party SDKs | Each is a dependency and a credential. | | Store status: last release, current targets | How far from shippable it is today. | | Tests and CI | Usually none. The safety net comes first. | Each answer goes into the report with its stage and a fixed price. ## Questions Q: Is Ionic still supported? A: The framework and Capacitor are, and they're open source. Ionic's commercial products are being wound down after the OutSystems acquisition, and Appflow closes at the end of 2027. Old Ionic apps have the older problem of AngularJS and Cordova underneath them. Q: Do we have to move off Cordova? A: Yes, in practice. Cordova is maintained by a small community and its plugins are what break when the stores raise their targets. Capacitor is the current runtime, made by the same people as Ionic, and the migration keeps your web code. Q: Our builds go through Appflow. What happens in 2027? A: Appflow closes on 31 December 2027. The build configuration has to be reproduced in a pipeline you own before then, and it's part of the first stage of any Ionic takeover we do. Q: Is it a rewrite? A: For Ionic 1, the components are rewritten because AngularJS is a different framework from modern Angular; the logic and the data handling carry across. For Ionic 4 onwards it's a series of upgrades, not a rewrite. Q: How long until we can ship an update? A: It depends on the versions, the plugins and whether the keys exist, which the assessment measures. The shape is the usual one: a build in the test tracks within about six weeks, then stages, each priced before you commit. --- # JasperReports modernisation and replacement URL: https://www.solvewithsoftware.com/modernise/jasperreports Title: JasperReports Modernisation Description: The JasperReports library lives on, the free server went in 2024, version 7 needs Java 17. Upgrade in place, or rebuild each report. From £395 + VAT. Last reviewed: 2026-09-04 JasperReports is the reporting layer under many Java and PHP business systems, and it has split in two. The library that fills a template and produces the PDF is still open source and still maintained; the free community edition of JasperReports Server, which scheduled and served those reports, was withdrawn on 25 January 2024 and gets no security fixes. Version 7 of the library also needs Java 17 and won't load templates from version 6 without conversion. Solve With Software inventories every .jrxml template, extracts what each one does, then either upgrades the library in place or rebuilds the reports on the modernised system, with each one matched against the old output before it switches. ## Where JasperReports stands Split down the middle. The JasperReports Library, the part that fills a .jrxml template with data and produces the PDF, is still open source under the LGPL, still maintained, and on version 7. Jaspersoft Studio, the designer, is still free. JasperReports Server is a different story. The web application that holds the report repository, schedules the overnight runs and lets users run reports themselves lost its community edition on 25 January 2024. The downloads were withdrawn, an existing install keeps running but is no longer maintained, and there are no fixes for security vulnerabilities. The commercial edition continues, and support for the 8.0.x line ended on 31 December 2024. The company behind it has changed hands three times, to TIBCO in 2014, to Cloud Software Group in 2022 and to HCLSoftware in July 2026. Version 7 of the library moved the ground as well. It needs Java 17, and templates saved by version 6 or older can't be loaded by version 7 on its own; they have to be converted in Jaspersoft Studio 7 first. A system on Java 8 with a folder of old .jrxml files has more than a library upgrade in front of it. ## Where JasperReports turns up In Java business systems (https://www.solvewithsoftware.com/modernise/java), mostly, and in a lot of PHP ones. Spring and JSF applications from the 2000s and 2010s with a reports package that calls the library. PHP systems (https://www.solvewithsoftware.com/modernise/php) that start a Java process to render invoices and statements. ERPs and customer portals a supplier built and left. The odd Oracle APEX install. In each case the .jrxml templates hold the invoice, the statement, the picking list, the month-end pack, and often the rules for what goes on them: an expression that works out the discount, a subreport that reads a table the application forgot, a scriptlet nobody has opened since it was written. The templates were designed in iReport, the older designer Jaspersoft retired in 2015, or in Jaspersoft Studio, and the person who designed them has usually gone. ## What modernising JasperReports involves 1. **Inventory.** Every .jrxml and compiled .jasper file, where it's called from, who runs it and how often. On a JasperReports Server install, the repository and the schedules tell most of it. Half are usually dead. The ones that remain are the specification. 2. **Extract what each report does.** The query or the stored procedure, the parameters, the expressions and scriptlets, the grouping and totals, the subreports, the layout. Written down as a description, so the rules survive whatever happens to the template. 3. **Choose the route.** Upgrade the library in place where the application is staying on Java, converting the templates in Jaspersoft Studio 7 as part of the upgrade. Replace the community edition server with scheduling and a report library inside the application. Rebuild the reports on the modernised system's reporting layer where the application is leaving Java or PHP. Often a mix. 4. **Move or rebuild each report** and run it side by side with the old one on the same data. Totals, row counts, and the layout the customer recognises on an invoice. A report doesn't switch until it matches. 5. **Retire what's left** when the last schedule has moved: the unmaintained server, the old Java runtime, the shell-out from PHP. Each report is a small stage of its own, which is why the work can be priced as a fixed number and done in the order the business cares about. ## Keep the library or replace it? **Keep it where the application is staying on Java; replace it where the application is leaving.** The library is maintained, free and good at what it does, so a Java system that is being modernised in place keeps it: upgrade to version 7, convert the templates, move the scheduling out of the withdrawn server and into the application. That is a contained piece of work with a known end. Where the application is being rebuilt on something else, the templates are a specification rather than a dependency. Each report is rebuilt on the new system's reporting layer, and the library goes with the old application when the old application goes. The community edition server is the one thing that doesn't stay in either case. Unmaintained software that holds the report repository and the database credentials for it is the first thing to move. ## Your data Untouched. Reports read; they don't change anything. The upgraded or rebuilt reports run against the same database as the old ones, side by side, until each matches. Where the new reporting layer needs views or a reporting database of its own, they are built and tested on a copy, then in staging alongside live, before anything connects to the live server. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For JasperReports it inventories the templates and any server install, identifies which reports are alive, extracts what a sample of them do, checks the Java version and the template versions against what version 7 needs, and prices the work report by report as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting An unmaintained JasperReports Server holding the report repository and a database login, reachable from the office network or wider. A Java 8 runtime that a hosting or security change will retire, taking the reports with it. Templates from version 6 that won't load after a well-meant library upgrade. And the rules that live only in report expressions being lost in a modernisation that didn't inventory them. ## How we approach it Inventory first, then match every report before switching it. Reporting layers are where we start on most takeovers, because the outputs are the part of the system the business can check line by line. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a JasperReports migration | Check | Why it matters | |---|---| | Library version, and the Java version it runs on | Version 7 needs Java 17; sets whether an in-place upgrade is a step or a project. | | Template versions: saved by version 6 or older? | Old templates need converting in Jaspersoft Studio 7 before version 7 will load them. | | JasperReports Server: community or commercial edition, and its version | The community edition is unmaintained since January 2024; 8.0.x support ended December 2024. | | Every .jrxml and .jasper file, who runs it, how often, and from where | Dead reports don't move; live ones are the specification. | | How the application calls it: Java in-process, a PHP shell-out, a REST call to the server | Decides what has to be rebuilt around the report, not just the report. | | Queries, stored procedures and data adapters | Some reports read from tables the main system forgot; each has to be found. | | Expressions, scriptlets and subreports | Where the business rules hide. Each is extracted and written down. | | Schedules and delivery: email, file share, portal | The reports nobody runs by hand, and the first thing missed after a move. | | Output formats: PDF, Excel, CSV, print | Each is a requirement of the new reporting layer. | Each answer goes into the report with a fixed price per report. ## Questions Q: Is JasperReports still supported? A: The JasperReports Library is, and it is still open source; version 7 is current. JasperReports Server community edition is not: it was withdrawn on 25 January 2024 and gets no maintenance or security fixes. The commercial edition of the server continues. Q: Our JasperReports Server is the community edition. Is it safe to keep running? A: It keeps working, but it has had no security fixes since January 2024 and holds the credentials for your database. We treat it as the first thing to move, either into scheduling inside the application or onto a supported reporting layer. Q: Can we upgrade to JasperReports 7 in place? A: If the application can run on Java 17, usually yes. The templates are the catch: anything saved by version 6 or older has to be converted in Jaspersoft Studio 7 first, and every converted report is run side by side with the old one until it matches. Q: Our PHP system prints invoices through JasperReports. Can you keep that? A: Yes, while the PHP system is being modernised in stages. The reports keep running through the library until the invoicing stage moves, and then they are rebuilt on the new system's reporting layer with the old invoice as the specification. Q: Can you replace the reports without touching the application? A: If they run on a JasperReports Server against the database, yes: the server can be replaced on its own. If the application calls the library directly, the reports move as part of modernising it, usually as the last stage. The assessment establishes which you have. --- # Old Java application modernisation URL: https://www.solvewithsoftware.com/modernise/java Title: Old Java Application Modernisation Description: Struts, JSP, Hibernate 3, Java 6 to 8: the language is alive, the stack isn't. Current Java in stages, or out of Java piece by piece. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software modernises Java web applications built between about 2003 and 2015: Struts 1, JSP and servlets, EJB, Hibernate 3, Spring 2 to 4, on Java 6, 7 or 8, running on Tomcat, JBoss, WebLogic or WebSphere. Java itself is in good health, which makes staying a real option: current Java, Spring Boot 3, the Jakarta namespace and a build that runs on a current machine, in stages. Where the web layer is Struts 1 or JSP, that part is rebuilt alongside. The assessment reads the application and prices each stage as a fixed number. ## Where old Java stands The language is fine. Java 25 is the current long-term release, Java 21 and 17 are supported, and free OpenJDK builds cover all of them. What's out of support is the stack a 2008 application was built on: - **Java 8** lost Oracle's free public updates for commercial use in January 2019. Oracle sells extended support to December 2030; free builds from other vendors carry on, but every framework has moved past it. - **Struts 1** reached end of life in April 2013, with its last release in December 2008. Struts 2 is a different framework, not an upgrade. - **Spring Framework 5.3**, the last version that runs on Java 8, left open-source support in August 2024, and Spring Boot 2.x in November 2023. Spring 6 and Boot 3 need Java 17 or later. - **The namespace.** In 2020, Jakarta EE 9 renamed every javax.* package to jakarta.*. Tomcat 10 and later, and every current application server, use the new names, so an old application won't even deploy there without code changes. Tomcat 9 is the last version that speaks the old names. - **Everything else.** Hibernate 3, EJB 2, Ant builds, applets, a WebLogic or WebSphere licence the business is still paying for. ## Stay in Java, or leave? **Stay and modernise** when the business logic is sound and the team, or the market you hire from, knows Java. The path is well trodden: current JDK, Maven or Gradle, Spring Boot 3, the Jakarta namespace, Hibernate 6, a current Tomcat or a container, and the Struts or JSP web layer rebuilt in stages. Most of the application survives. **Leave in stages** when the web layer is most of the application and would be rebuilt anyway, when nobody left knows Java, or when the rest of the estate is on .NET or the web stack and one more platform is the cost. Then the new system is built alongside, in whatever the business can support, one process at a time behind a proxy, with the Java application still serving what hasn't moved. **Often the first, then the second.** Get it building and supported first, because that removes the risk; then decide the rest with the pressure off. The assessment makes the call from the code. ## The staged path 1. **Get it building** on a current machine, from source control, with the dependencies resolved. Old Ant builds and jars checked into the tree are where the first surprises are. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) does this first. 2. **Safety net.** A test environment, a staging environment, and tests around the processes that matter, before any version changes. 3. **Step the JDK.** 8 to 11 to 17 to 21 or 25, fixing what each step removes. Reflection, removed modules and old crypto are the usual ones. 4. **Step the frameworks.** Spring 4 to 5.3 to 6, Hibernate 3 to 6, and the Jakarta namespace change, which is mechanical but touches every file. 5. **Replace the web layer** where it's Struts 1 or raw JSP: one screen or one module at a time, alongside the old one, behind a proxy. 6. **Move the hosting.** Off the licensed application server onto Tomcat or a container, in your own accounts. Each stage has its own fixed price and each ends with the application running on something supported. ## Your data Usually Oracle, SQL Server or MySQL, and it stays where it is. Hibernate upgrades change the generated SQL, so the data layer never meets a change until the change has proven itself somewhere else: tested against a copy in a test environment, then run in staging against the live schema with results reconciled, before anything connects to live. ## Can this be done gradually? **Yes. The JDK and framework steps each leave the application running and deployable.** The web layer moves one screen at a time behind a proxy. A leave-in-stages plan runs the new system alongside and re-points one process at a time. Stop after any stage and keep everything. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Java application it gets the thing building, maps every dependency and framework version, identifies what upgrades in place and what's rebuilt, and prices the stages as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting An application on Java 8 and Spring 4 gets no fixes for anything in its stack, and Java web frameworks have a history of serious vulnerabilities. Each year the gap to current versions widens and the upgrade gets longer, not shorter. And the application server licence keeps being paid for a platform the application doesn't need. ## How we approach it Get it building, make it safe, step the versions, rebuild the web layer alongside. Marc Allington has built in Java and the enterprise middleware around it, and builds in Java, .NET and the web stack now, so both staying and leaving are familiar ground. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for an old Java application | Check | Why it matters | |---|---| | JDK version in production, and does the source build on a current machine? | Sets the number of JDK steps. If it doesn't build, that's stage one. | | Build: Ant, Maven, Gradle, or jars in the tree | Old Ant builds with checked-in jars hide the real dependency list. | | Web layer: Struts 1, Struts 2, JSP, JSF, Spring MVC, GWT | Struts 1 and raw JSP are rebuilt; Spring MVC mostly upgrades. | | Frameworks: Spring version, Hibernate version, EJB, JAX-WS | Each has its own upgrade path and its own breaking changes. | | javax.* usage, and which application server | The Jakarta namespace change touches every file and decides the server. | | Application server: Tomcat, JBoss, WebLogic, WebSphere, and its licence | Whether hosting moves and what it saves. | | Integrations: MQ, SOAP services, batch jobs, file drops | Every one has a caller or a schedule to keep working. | | Tests, source control, deployment process | The safety net comes before any version step. | Each answer goes into the report with its stage, its consequence and a fixed price. ## Questions Q: Is Java a dead end? A: No. Java 25 is the current long-term release and the ecosystem is active. What's dead is the 2008 stack: Struts 1, Java 8 on free updates, Spring 4. Staying in Java and modernising is a real option, and often the cheaper one. Q: Our application is Struts 1. Can it be upgraded? A: Not in place. Struts 1 has been end of life since 2013 and Struts 2 is a different framework. The web layer is rebuilt one screen at a time, usually in Spring MVC or a modern front end, with the business logic underneath kept and upgraded. Q: We're on Java 8. Is that unsupported? A: Oracle's free public updates for commercial use ended in January 2019; paid extended support runs to December 2030, and other vendors ship free builds. The practical problem is that current frameworks need Java 17 or later, so staying on 8 means staying on old frameworks too. Q: What is the javax to jakarta change? A: In 2020 Java EE became Jakarta EE and every javax.* package was renamed jakarta.*. Current servers, including Tomcat 10 and later, use the new names. The change is mechanical but touches every file that imports them, and it's one of the stages. Q: How long does a Java modernisation take? A: It depends on how many JDK and framework steps there are and how much of the web layer is Struts or JSP, which the assessment counts. The shape is the same as always: building and safe first, something on a supported version within about six weeks, then one stage at a time, each priced before you commit. --- # Microsoft Access modernisation and replacement URL: https://www.solvewithsoftware.com/modernise/microsoft-access Title: Microsoft Access Modernisation Description: An Access database that became the whole operation, slow and corrupting under load. Three paths out, data to SQL Server first. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over Microsoft Access databases that have grown into the business system, and modernises them in stages: first the data to SQL Server, which fixes the speed and the multi-user problems while the screens stay the same, then the screens to the web one process at a time if you need them outside the office. Nothing is rewritten until the assessment has read the tables, the queries and the VBA and put a fixed price on each path. ## How an Access database becomes the system Somebody in the office built it to track one thing. It worked, so it grew. Years later it holds the customers, the orders, the stock and the invoicing, half the office opens it every morning, and the person who built it has moved on. That's the normal history of an Access system, and it's not a failure. Access is a good tool for the job it was designed for: a handful of users on one office network. The trouble starts when the business outgrows that design, and the symptoms are always the same. - It's slow, and slower still for anyone working from home over a VPN. - It corrupts. Compact and repair has become a weekly job, and everyone knows the phrase "unrecognised database format". - Two people editing the same record produces a locking error, or silently loses one edit. - The file is near the 2 GB limit, or has been split into several files that don't quite agree. - Nobody dares change a query because nobody knows which reports depend on it. ## What we usually find inside Three things, and they're worth different amounts. **The tables.** The data model is the most valuable part and usually the soundest. It reflects what the business tracks. It often needs tightening (missing keys, free-text fields doing the work of a lookup, dates stored as text), but it's a head start on any replacement. **The queries and the VBA.** This is where the business rules live: the pricing logic, the status transitions, the "if the customer is on hold, don't allow despatch" checks. It's also where the undocumented behaviour hides. Reading it is most of the assessment. **The forms and reports.** Useful as a specification for what the screens need to do. Rarely worth carrying forward as they are, because they're the part tied to the desktop. ## The three paths **Move the data to SQL Server, keep the Access front end.** Access links to SQL Server tables and carries on looking exactly as it did. The 2 GB limit, the corruption and most of the speed problems go, because the data is no longer a file on a share being read by thirty PCs. Multi-user locking becomes SQL Server's job, which it does properly. Queries that ran in Access can be moved into views and stored procedures so the heavy work happens on the server. This is the first stage for almost every Access system, and for some it's the whole answer for years. **Replace the front end with a web application, in stages.** When people need the system outside the office, on a phone, or shared with customers, the desktop front end is the limit. With the data already on SQL Server, a web screen can replace one Access form at a time while the rest of the system carries on in Access against the same tables. The VBA rules move across as they're understood. The old form stays until the new one has proven itself. **Replace the whole thing.** Right when the data model itself is the problem, or when the business has changed so much that the system's shape is wrong. Even then, replace alongside, with the data moved and reconciled before anything switches, and the Access tables and VBA read as the specification. Which path fits is what the assessment decides, from the tables, the queries and the code rather than from a description. ## What moving to SQL Server involves Less than people fear, done in the right order. 1. **Read the schema and clean what has to be clean.** Every table needs a primary key SQL Server can use. Dates stored as text, Yes/No fields with nulls, and lookup values typed by hand all have to be resolved before they move, or they'll break on the way. 2. **Move the tables**, using the Microsoft migration tools where they fit and hand-written scripts where they don't. Attachment and multi-value fields, which SQL Server doesn't have, get redesigned. 3. **Re-link the front end.** The Access forms now point at SQL Server. Queries that were doing joins across linked tables get rewritten as views or pass-through queries so the work happens on the server. 4. **Test against a copy, then run in staging alongside the old file** with the same data, reconciling record counts and totals until they match. 5. **Switch**, at a quiet moment, with the old file kept read-only as a fallback. At the end the users see the same screens, and they're faster, and the weekly compact and repair is over. ## Your data Nothing changes during the assessment. When the data moves, it moves once, and it never meets a change until the change has proven itself somewhere else: built and tested on a copy in a test environment, then run in staging alongside the live database with record counts, totals and a sample of records reconciled. Only when the tests have shown it's safe does anything connect to live, and the Access file stays available as a fallback until you're confident. ## Can this be done gradually? **Yes, and Access is unusually well suited to it.** Because the front end and the data can be separated, the data move is a stage on its own with an immediate result, and every form after that is a stage of its own. The office keeps working in Access throughout. There is no cutover weekend and no leap. ## What it costs The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an Access system it reads the tables, queries, VBA and reports, tests the file's health, and prices each path as a fixed number. The data move is usually the first stage and the cheapest. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of leaving it Corruption is the one that ends badly. An Access file on a network share, opened by many people, will corrupt eventually, and the question is whether the last backup was tested. The others are slower: the 2 GB limit arriving, the one person who understands the VBA leaving, and remote working turning a slow system into an unusable one. ## How we approach it Understand first, then move the data, then modernise the screens one at a time. Marc Allington has built business systems on Access and SQL Server as well as on the web, so the queries and the VBA are familiar ground. Everything we build afterwards runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for an Access takeover What the assessment establishes for an Access system, and why each item matters: | Check | Why it matters | |---|---| | Is it split into front end and back end, or one file? | One file shared on a network is the corruption risk. A split makes the data move straightforward. | | Version and format: .mdb or .accdb, and which Access release? | Sets which migration tools apply and which features (attachments, multi-value fields) need redesign. | | File size and record counts | Distance from the 2 GB limit, and how long the data move will take. | | Do all tables have usable primary keys? | SQL Server needs them; adding them is the first cleaning job. | | Where do the business rules live: queries, VBA, macros, or form events? | Determines how much of the logic moves to the server versus the screens. | | Which reports and exports depend on it? | Reports are the part most often forgotten in a move, and the part the finance team notices first. | | How many users, and from where? | Office-only versus remote is the difference between the data move being enough and a web front end being needed. | | Is there a tested backup? | If not, that's the first job, before anything else changes. | Each answer goes into the report with its consequence for the three paths and a fixed price for each. ## Questions Q: Can we keep using Access? A: Yes, and for many businesses that's the right first step. Moving the data to SQL Server and keeping the Access front end fixes the speed, the corruption and the multi-user problems without changing a screen. Whether to go further is a separate decision, priced separately. Q: Why is our Access database so slow? A: Usually because every PC opening it is pulling the data across the network to do its own filtering. On a VPN that becomes unusable. Moving the data to SQL Server puts the work on the server, which is the single biggest speed improvement available. Q: It keeps corrupting. Can that be fixed? A: Yes. A shared Access file will corrupt under multi-user load; that's the design, not bad luck. Moving the data to SQL Server ends it, because SQL Server is built for many users at once. Until then, the priority is a backup that has been tested. Q: We have a lot of VBA. Does that have to be rewritten? A: Not for the data move. The VBA keeps working against linked SQL Server tables, with some queries adjusted. It has to be carried across when a form moves to the web, and by then it's been read and understood, which is most of the work. Q: Should we go straight to a web application? A: Only if the data is already on SQL Server or moves there first. Going from a single Access file straight to a web app in one step is the big-bang rewrite, and it's where these projects fail. Data first, then screens, one at a time. --- # Native iOS and Android app takeover URL: https://www.solvewithsoftware.com/modernise/native-mobile-apps Title: Native iOS and Android App Takeover Description: A native app the developer left: Objective-C, early Swift, Java or Kotlin, on tooling the stores reject. Updated, then modernised. From £395 + VAT. Last reviewed: 2026-09-04 A native app has two codebases, two toolchains and two sets of store rules, and an old one usually fails all of them at once: Objective-C or early Swift that current Xcode rejects, Java or early Kotlin that won't target current Android, and accounts and keys in the developer's name. Solve With Software takes both codebases over, brings each up to what the stores accept now, moves the accounts and keys into your name, and then modernises the app in stages or rebuilds it once in Flutter with the backend kept, on a fixed price from the assessment. ## Why a native app stalls Because the platforms move every year and the app didn't. Apple raises the minimum Xcode and SDK for App Store uploads each spring; since April 2026 that's Xcode 26 and the iOS 26 SDK. Google raises the target Android version each summer; from August 2026 updates must target Android 16, and apps that don't target Android 15 stop being visible to new users. An app last built in 2020 fails both, and the longer it's left, the more deprecated APIs, removed frameworks and changed permissions stand between it and a build. Add the human side: the developer who knew the Objective-C left, the Swift is a version nobody has the toolchain for, and the Android project opens in a Gradle version that no longer exists. ## What we usually find Two projects in different states. The iOS one in Objective-C, or Swift from a version several majors back, using frameworks Apple has since removed. The Android one in Java with a support library that became AndroidX years ago, and a build that fails before it starts. A shared backend that's usually fine. Certificates that expired. A keystore on someone's old laptop. A Firebase project in the developer's account. The app's logic and design are usually worth keeping. The toolchain around them has moved on without them. ## The accounts and keys you need to own This matters more for native apps than anything else, because there's no way around it. The Apple Developer account and App Store Connect access, the signing certificates and provisioning profiles. The Google Play Console account, the upload key, and whether Play App Signing holds the app signing key or the developer did. Push certificates. The backend and Firebase accounts. Third-party SDK keys. If the Android signing key is lost and Play App Signing was never enabled, the existing listing cannot be updated and the app has to be republished as a new one, losing its reviews and its install base. Establishing where the keys are is the first thing the assessment does. ## The paths **Take it over and get it building.** Both projects into your repository. Current Xcode and Android tooling. The deprecated and removed APIs replaced, one at a time, until each project builds and passes the store checks. Accounts and keys moved into your name. Builds into the test tracks. This is the first stage, always, and it's the one that makes updates possible again. **Modernise in place.** Objective-C to Swift and Java to Kotlin file by file, with the app shipping throughout. Newer frameworks (SwiftUI, Compose) for new screens while old screens stay until they're rebuilt. The right path when the app has a long future on both platforms and the native experience matters. **Rebuild once in Flutter.** One codebase for both platforms, the backend and the design carried across, the two old projects retired when the new one has proven itself through the test tracks. The right path when the app is small, when maintaining two native codebases is the thing the business can't sustain, or when both projects need so much work that a rebuild is cheaper. We build in Flutter, and the assessment compares it on cost. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) gets both projects building, audits the accounts, and prices each path as a fixed number. ## Your data Behind an API or in Firebase, and it stays where it is, in an account you own. Nothing reaches your users until it has proven itself somewhere else: a build tested against a staging backend, released to a test group through TestFlight and the Play internal track, then to the store, with the previous version still live until the new one is trusted. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a native app it gets both projects building in a clean environment, lists what the stores reject, establishes the accounts and keys, and prices the takeover, the modernisation and the rebuild as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting An app that can't ship a fix, because it can't be built for what the stores accept, which is the position of most apps last built before 2024. An app that disappears from Google Play search for new users because it targets an old Android. A lost keystore. A lapsed developer account, which takes the app off the store entirely. And the annual step-up in requirements that makes every year of delay more expensive than the last. ## How we approach it Keys and accounts first, then a build on each platform, then the decision between modernising two codebases and rebuilding one. Marc Allington has built native iOS and Android apps and builds mobile apps in Flutter now, so the comparison is made from both sides. Everything we build runs in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a native app takeover | Check | Why it matters | |---|---| | iOS: language and version (Objective-C, Swift N), and does it build with current Xcode? | The distance to a build the App Store will accept. | | Android: language, Gradle and target SDK, and does it build with current tooling? | The distance to a build Google Play will accept. | | Apple Developer account, certificates, profiles: whose name, do they exist? | Without them no iOS build ships. | | Google Play account, upload key, Play App Signing | A lost key without Play App Signing means a new listing. | | Deprecated and removed frameworks and APIs in each project | The size of the first stage. | | Backend, Firebase, push, third-party SDKs and their keys | Each is a dependency and a credential. | | Store status: last release, current targets, visibility, pending rejections | How far from shippable it is today. | | Shared logic between the two projects | Decides how much a Flutter rebuild would save. | Each answer goes into the report with its stage and a fixed price. ## Questions Q: Do you handle both iOS and Android? A: Yes. A native app is two projects and they're taken over together, because the accounts, the backend and the release process are shared even where the code isn't. Q: We don't have the Android signing key. Is the app lost? A: If Play App Signing was enabled, no: Google holds the signing key and the upload key can be reset. If it wasn't, the existing listing can't be updated and a new listing is needed, which loses reviews and installs. Establishing which is the first thing we do. Q: Should we rebuild it in Flutter? A: Sometimes. One codebase instead of two is a real saving if the app is small or both projects need heavy work. It's a worse answer when the app depends on native features that matter. The assessment prices both and says which. Q: It's Objective-C. Can that still be built? A: Yes. Current Xcode still compiles Objective-C. What usually fails is the removed frameworks and the changed permissions around it, which are fixed one at a time until the project builds and passes the store checks. Q: How long until we can ship an update? A: It depends on how far each project is from a build the stores accept, and whether the keys exist, which the assessment measures. The shape is the usual one: both platforms in the test tracks within about six weeks, then stages, each priced before you commit. --- # PhoneGap and Cordova app migration URL: https://www.solvewithsoftware.com/modernise/phonegap-cordova Title: PhoneGap and Cordova App Migration Description: PhoneGap is gone, Cordova is fading, but the web app inside is usually fine. Moved to Capacitor, or rebuilt, and back in the stores. From £395 + VAT. Last reviewed: 2026-09-04 PhoneGap was shut down by Adobe in 2020, and Apache Cordova, the open-source project underneath it, is maintained by a small community whose plugins are the first thing to break when Apple and Google raise their requirements, as both did in 2026. The web application inside the shell is usually fine. Solve With Software keeps that code, replaces the shell with Capacitor, rewrites or replaces the plugins that have no equivalent, and gets the app shipping through the stores again, in stages, on a fixed price from the assessment. ## Where PhoneGap and Cordova stand PhoneGap is over. Adobe closed it and PhoneGap Build in 2020, so any app that was built through PhoneGap Build has had no build pipeline for years. Cordova, the Apache project PhoneGap was built on, still exists and still releases, but it's a small community keeping it going, and the plugin ecosystem it depends on has thinned to the point where the plugin your app needs is often unmaintained. The stores are the forcing function. Since April 2026 App Store uploads need Xcode 26; from August 2026 Google Play updates need to target Android 16. An old Cordova plugin that was written against a much older platform often can't be built for those targets, so the app can't ship a fix, however small. ## What carries over The app. A PhoneGap or Cordova app is HTML, CSS and JavaScript in a native wrapper, and that web code doesn't care what wrapper it's in. Screens, logic, data handling and the backend it talks to all survive. Often the web code is jQuery Mobile or an early framework, which dates it but doesn't stop it working. What doesn't carry over is the wrapper and the plugins. Camera, geolocation, file access, push, barcode scanning: each one was a Cordova plugin, and each needs a Capacitor equivalent, a rewrite, or a decision that the app no longer needs it. ## The paths **Move the shell to Capacitor.** Capacitor is the maintained wrapper made by the Ionic team, and it's designed to take an existing web app. The web code moves as it is, each Cordova plugin is mapped to its Capacitor equivalent (many exist) or rewritten, and the app builds with current Xcode and current Android tooling. The right path when the web app does its job and the business wants it as it is. **Move the shell and modernise the web code.** Same as above, then the web app itself brought forward from jQuery Mobile or whatever it was to a current framework, screen by screen. The right path when the app has a future and the old web code is holding it back. **Rebuild in Flutter.** When the app is small, or when a wrapped web app was the wrong fit for what it does: heavy camera or maps use, offline work, anything where the shell was always the weak point. The backend and the design carry across. We build in Flutter, so the assessment compares it on cost. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) reads the app and the plugin list and prices each path as a fixed number. ## The accounts and keys you need to own Old apps are the ones most likely to have lost track of these. Apple Developer account, certificates and profiles. Google Play account, the upload key, and whether Play App Signing holds the signing key. If PhoneGap Build did the signing, the keys were uploaded there, and where they are now is a question. The backend account. Push certificates. The assessment establishes each before anything else, because without them no build ships. ## Your data Behind an API or a hosted backend, and it stays where it is, in an account you own. Nothing reaches your users until it has proven itself somewhere else: a build tested against a staging backend, released to a test group through TestFlight and the Play internal track, then to the store. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a PhoneGap or Cordova app it inventories the plugins and their Capacitor equivalents, checks the accounts and keys, and prices the shell migration and the rebuild as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting An app that can't ship a fix. That's the position of most PhoneGap apps today, because the build pipeline is gone and the plugins can't meet the store targets that arrived in 2026. After that: a phone operating system update that breaks a plugin, a lapsed developer account, and keys that were in PhoneGap Build and nowhere else. ## How we approach it Keys and accounts first, then the shell, then the plugins one at a time, then the web code if it needs it. Marc Allington has built and wrapped web applications for mobile and builds mobile apps in Flutter now. Everything we build runs in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a PhoneGap or Cordova takeover | Check | Why it matters | |---|---| | PhoneGap Build or local Cordova, and which Cordova version | PhoneGap Build means no pipeline and possibly no keys; the version sets the migration distance. | | Plugin inventory, and which have Capacitor equivalents | The migration's real cost. | | The web code: framework, version, and does it run in a browser on its own? | If it runs in a browser, the shell can be swapped under it. | | Apple and Google accounts, keys, Play App Signing | Without them no build ships; PhoneGap Build may have held them. | | Backend and push | Where the data and notifications live, and in whose account. | | Store status: last release, current targets | How far from shippable it is today. | | Device features used: camera, location, files, scanning | Each is a plugin decision. | | Tests | Usually none. The safety net comes first. | Each answer goes into the report with its stage and a fixed price. ## Questions Q: Our PhoneGap app still works on people's phones. Why change it? A: Because you can't change it. Without a build pipeline that meets the current store requirements, no fix, however small, can be shipped. It works until the next phone update breaks something, and then it doesn't. Q: Do we lose the app and start again? A: No. The web code inside the shell carries over as it is. Capacitor is designed to wrap an existing web app, and the plugins are the only part that has to change. Q: PhoneGap Build had our signing keys. Are they gone? A: Possibly. If Play App Signing was enabled, Google holds the Android signing key and the upload key can be reset. Apple certificates can be reissued from the developer account. Establishing what exists is the first job. Q: Would a rebuild in Flutter be better? A: For a small app, or one where the wrapped-web approach was always the weak point, sometimes. The assessment prices both. Keeping the web code and swapping the shell is usually cheaper when the app does its job. Q: How long until we can ship an update? A: It depends on the plugin list and whether the keys exist, which the assessment measures. The shape is the usual one: a Capacitor build in the test tracks within about six weeks, then stages, each priced before you commit. --- # Old PHP application modernisation URL: https://www.solvewithsoftware.com/modernise/php Title: Old PHP Application Modernisation Description: PHP 5 or 7, a dead framework, forgotten hosting. We take the system over, move it to supported PHP you own, and modernise in stages. From £395 + VAT. Last reviewed: 2026-09-04 Most old PHP business systems Solve With Software takes over are on PHP 5 or 7, both long out of support, on a framework that stopped being maintained and hosting that was set up by someone who has left. Only PHP 8.2 to 8.5 are supported in September 2026, and 8.2 ends on 31 December 2026. We take the code over, get it running on a supported PHP version on hosting you control, and then modernise it in stages, keeping the rules and the data throughout. ## Where old PHP stands PHP itself is healthy. The problem is which PHP. In September 2026 the supported versions are 8.2, 8.3, 8.4 and 8.5, and 8.2 reaches end of life on 31 December 2026. PHP 8.1 ended last December. PHP 7 ended in 2022. PHP 5 ended in 2018, and a surprising number of business systems still run on it, because the hosting provider never forced the change and the application never broke. Each major version removed things the old code relied on. The move from 5 to 7 took away the original MySQL extension that half of PHP 5 code used for every query. The move to 8 tightened types and errors so that code which used to limp along now stops. That's why an old PHP system can't simply be moved to a new server: the server's PHP is the new one, and the code isn't. ## What we usually find One of four shapes: - **A framework of its era.** CodeIgniter 2 or 3, CakePHP 2, Zend Framework 1, Symfony 1, or an early Laravel. Some of these have modern successors; some don't. - **A framework the developer wrote.** Their own router, their own database layer, their own templating. Readable, usually, and entirely dependent on conventions that lived in their head. - **A WordPress site that became the system.** Plugins and custom code holding orders, members or bookings, on a WordPress that can't be updated because the custom code would break. - **Plain PHP.** Files that mix HTML, logic and SQL, one per page, from the days when that's how it was done. Under all four there's usually MySQL with a sound data model, hosting on a shared server or a single VPS with no staging environment, FTP deployment, and no source control. The rules are in there. They're just tangled up with everything else. ## The paths **Get it onto supported PHP, as it is.** Take the code into source control, stand it up on a test server running a current PHP, and fix what breaks: removed extensions, changed behaviour, deprecated syntax. For plain PHP and self-written frameworks this is often a contained piece of work, and it takes the system off the end-of-life list without changing what users see. It's the first stage whatever follows. **Modernise in stages onto a maintained framework.** Usually Laravel. The data model stays; the rules move across one process at a time into a proper structure with tests, with the old application running alongside on the same database until each process has moved. The right path when the business still wants the system and wants to keep changing it. **Replace.** When the data model is the problem or the business has changed shape. Even then, alongside, with the data shared until the new system has proven itself. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) reads the code and prices each path as a fixed number. ## Hosting and the things nobody remembers Old PHP systems live in odd places: a shared hosting account in the founder's name, a VPS nobody has logged into since 2020, a server at the old developer's office. Part of the takeover is finding where it runs, who owns the account, whether there's a backup, and moving it to hosting you control, with a staging environment beside it so nothing is ever tested on live again. The domain, the DNS, the email and the SSL certificate are on the same list. ## Your data Usually MySQL, and it comes with you unchanged. Old and new run against the same database throughout a staged modernisation. Any change to the schema is tested on a copy, then in staging with the data reconciled, before anything connects to live, and the old application stays available as a fallback until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a PHP system it stands the code up on a supported PHP in a test environment to see what breaks, maps the rules and the hosting, and prices each path as a fixed number. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting An unpatched language runtime on a public web server. That's the risk with PHP 5 and 7, and it's the one insurers and Cyber Essentials assessors ask about. After that: a hosting provider that upgrades PHP without asking and takes the site down, a framework with a published vulnerability and no fix, and the plain fact that PHP 5 developers are as rare as VB6 ones. ## How we approach it Source control, a supported PHP and hosting you own first; then stages. Marc Allington has taken over PHP systems of all four shapes above and builds on Laravel now. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a PHP takeover | Check | Why it matters | |---|---| | PHP version in production, and what a current version does to the code | The end-of-life status, and the size of the first stage. | | Framework and version, and whether it's still maintained | Decides between fixing in place and moving to a maintained one. | | Database extension in use: mysql, mysqli, PDO | The original mysql extension is gone from PHP 7 onwards; every query using it has to change. | | Where it's hosted, who owns the account, and is there a backup that restores? | The account is often in someone else's name; the backup is often assumed. | | Deployment: FTP, git, something else | FTP means no history and no rollback. Source control is the first job. | | Where the rules live: framework code, plain pages, database | Sets how much has to be read before any process can move. | | Integrations and cron jobs | Payment gateways, email, scheduled tasks, all with credentials in someone's old inbox. | | Domain, DNS, SSL, email | Part of ownership, and often split across three providers. | Each answer goes into the report with its stage and a fixed price. ## Questions Q: Can't the host just upgrade PHP? A: They can, and it will break the site. Old code relies on things newer PHP removed. The fix is to stand the code up on a current PHP in a test environment first, fix what breaks, then move. That's the first stage. Q: Our system is built on WordPress. Is that different? A: The shape is different, the job is the same. Custom plugins and theme code hold the rules, and they're what stops WordPress being updated. The assessment reads them and prices either fixing them in place or moving the business logic out into a system of its own. Q: Do we have to move to Laravel? A: No. Getting onto supported PHP as it is can be the whole answer for a while. Laravel is where we'd take a system the business wants to keep changing, because it brings structure and tests. The assessment recommends one from the code. Q: We don't have the hosting login. Can you still help? A: Usually. The code can often be recovered from the running site, an old backup or the developer's repository, and the domain is recoverable through the registrar. Finding where everything is and who owns it is part of the assessment. Q: How long does it take? A: It depends on how much the code fights a current PHP and how tangled the rules are, which the assessment measures. The shape is the usual one: supported PHP on hosting you own within about six weeks, then stages, each priced before you commit. --- # React, Angular and Node apps the agency left behind URL: https://www.solvewithsoftware.com/modernise/react-angular-node Title: React, Angular or Node App Takeover Description: A React, Angular or Node app whose agency moved on. Not old, just stuck. We take it over, get it building, and move it forward. From £395 + VAT. Last reviewed: 2026-09-04 A React, Angular or Node application from 2018 to 2022 whose agency has stopped replying is a legacy system with a young face. The code is mainstream, which is the good news. The bad news is that AngularJS died in 2021, Node 20 went out of support in April 2026, Create React App was retired in 2025, and the hundreds of packages the app depends on have moved on without it. Solve With Software takes the code into your own repository, gets it building on supported versions, recovers the hosting and the credentials, and then modernises it in stages, on a fixed price from the assessment. ## Why a 2020 app is already legacy Because the ground moved. A modern web application is a few thousand lines you wrote on top of a few hundred packages you didn't, and those packages have release schedules of their own. - **AngularJS**, the original Angular, reached end of life in December 2021. Applications on it get no fixes unless you pay a third party for extended support. The move to modern Angular is a rewrite, not an upgrade. - **Angular** gives each major version 24 months. Angular 22 is current; anything more than two majors back is unsupported. - **Node.js 20** went out of support on 30 April 2026. Node 22 is in maintenance until April 2027; Node 24 is the version to be on. - **Create React App**, which most React projects of the era were started with, was retired in February 2025. It still runs; it's not maintained. - **Everything else**: a lock file with packages at 2020 versions, a build tool nobody has run in years, and a security scanner that lights up like a Christmas tree. Built in 2003 or 2020, stuck is stuck. If your business can't move it forward, it's a takeover. ## What we usually find A codebase that's readable and a project that won't build. The agency's laptop had the right Node version, the right environment variables and the deploy script, and none of that came with the handover. Somewhere there's a Firebase project, a Heroku account or an AWS bill in the agency's name. The database is Postgres or Mongo on a hosted service whose login is in an ex-employee's inbox. The application itself is usually fine. Rules in the API, screens in the front end, a data model that reflects the business. What it lacks is a home you control and a build that works on a machine that isn't the agency's. ## The paths **Take it over and get it building.** The repository into your organisation. Environment variables found or rebuilt. Node pinned to a supported version. A build that works on a clean machine, then in a test environment, then in staging. Hosting, database, domain and third-party services moved into accounts you own. This is the first stage, always, and it takes the app from "stuck" to "supportable" without changing what users see. **Upgrade in place.** Angular major by major, with the official migration tooling, each step tested. React off Create React App onto Vite or a framework, with the components unchanged. Node to the current long-term release with the packages that need it updated. Contained work, done in stages, each priced. **Rewrite the parts that can't upgrade.** AngularJS is the usual case: the components are rebuilt in modern Angular (or React, if the team prefers) one screen at a time, with a hybrid arrangement letting old and new run together until the last screen has moved. **Modernise and extend.** Once it builds and it's on supported versions, the app is yours to move forward: the features the agency never finished, the integration that was always phase two, AI where it pays back. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) reads the code and the package list and prices each path as a fixed number. ## The things you need to own, and probably don't Part of every takeover is a list of accounts, and it's usually longer than anyone expected: the source repository, the hosting, the database, the domain and DNS, email sending, file storage, the payment provider, the analytics, the error tracker, the app's own API keys to other services, and the developer accounts if there's a mobile app. Each one either moves into your name or gets recreated. The assessment produces the list; the first stage works through it. ## Your data Usually on a hosted database service, and it stays there or moves once into an account you own, reconciled on the other side. Nothing meets a change until the change has proven itself somewhere else: built and tested against a copy in a test environment, then run in staging, before anything connects to live. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a React, Angular or Node app it gets the code building in a test environment, audits the packages and the accounts, and prices the takeover and the upgrades as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting Packages with published vulnerabilities and no one applying the fix. A runtime out of support on a public server. A hosting account in the agency's name that lapses when the card does. And the widening gap: every month the app isn't upgraded, the upgrade gets harder, because more of the ecosystem has moved on. ## How we approach it Get it building, get it owned, then move it forward in stages. Marc Allington builds on React, Angular and Node and has taken over enough agency-built applications to know where the environment variables hide. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a React, Angular or Node takeover | Check | Why it matters | |---|---| | Does it build on a clean machine, and on which Node version? | The first failure tells you what the handover missed. | | Framework and version: AngularJS, Angular N, React with CRA or Vite, Next | Sets the upgrade path, and whether any part needs rewriting. | | Package audit: unmaintained, vulnerable, pinned to nothing | The security exposure and the size of the upgrade stage. | | Environment variables and secrets | Where they are, who has them, and which services they open. | | Hosting, database, domain, DNS, email, storage, payments: whose name? | The ownership list. Each moves or is recreated. | | Tests, CI, deployment process | Usually some tests and a deploy script that lives on someone's laptop. | | Integrations and API keys to third parties | Each is a dependency and a credential. | | Mobile app, if any, and the developer accounts | A separate ownership problem with its own store deadlines. | Each answer goes into the report with its stage and a fixed price. ## Questions Q: Our app is only a few years old. Is it really a legacy system? A: Age isn't the issue. Being stuck is. If nobody can build it, upgrade it or change it, it's a legacy system whatever year it was written, and the takeover is the same shape as for a VB6 one, with better tools. Q: The agency won't hand over the code. What can you do? A: Sometimes it's in a repository you already have access to and nobody realised. Sometimes it's recoverable from the deployed application. Sometimes the contract gives you the right to it and a letter gets it. The assessment establishes what you have before anyone spends money on a rebuild. Q: It's AngularJS. Can that be upgraded? A: Not in place. AngularJS ended in 2021 and modern Angular is a different framework. The screens are rebuilt one at a time, with old and new running together, and the API underneath usually carries on as it is. Q: Can we keep the agency's hosting? A: Only if the account moves into your name. Hosting, database and domain in someone else's account are the risk that turns a stuck app into a lost one. Moving them is the first stage. Q: How long does a takeover take? A: It depends on how far the packages have drifted and how many accounts have to move, which the assessment measures. The shape is the usual one: building, owned and on supported versions within about six weeks, then stages, each priced before you commit. --- # React Native app takeover URL: https://www.solvewithsoftware.com/modernise/react-native Title: React Native App Takeover Description: A React Native app the agency left: it won't build and the accounts are in their name. We take it over and get updates shipping. From £395 + VAT. Last reviewed: 2026-09-04 A React Native app that nobody can build is a common handover failure: the agency had the right Node, Xcode and Android tooling, and none of that came with the code. Meanwhile the stores moved. Since April 2026 the App Store requires builds from Xcode 26, and from August 2026 Google Play requires updates to target Android 16. Solve With Software takes the code into your repository, gets it building on current tooling, moves the accounts and keys into your name, and upgrades the app in stages so updates ship again. ## Why a React Native app stalls React Native moves fast, and an app pinned to a 2021 version has a lot of ground to cover. The native modules it depends on have been replaced or abandoned. The Expo SDK it was built on, if it used one, has had several majors since. The new rendering architecture became the default in late 2024, and older native modules don't work with it. Then the stores add their own clock. An update that can't be built with current Xcode can't be uploaded to the App Store. An update that doesn't target current Android can't be published on Google Play. So an app that runs fine on customers' phones today can't be changed at all, which is the definition of stuck. ## What we usually find JavaScript that's readable and a project that won't build. Node pinned to nothing. A lock file from the year it shipped. Native modules with no maintainer. A Podfile that resolves to versions Xcode won't accept. Signing certificates that expired. A Google Play keystore on the agency's machine. Push notifications through a Firebase project in the agency's account. The application logic is usually fine. What's missing is a home, current tooling, and the keys. ## The accounts and keys you need to own Mobile apps have an ownership problem that web apps don't. The Apple Developer account, App Store Connect access, the signing certificates and provisioning profiles. The Google Play Console account and the upload key, plus whether Play App Signing holds the app signing key or the agency does. The Firebase project for notifications and often for the backend. The push certificates. Any third-party SDK keys. If the Android upload key is lost and Play App Signing was never enabled, the app cannot be updated under its existing listing at all. That's the single most important thing to establish on day one, and the assessment does. ## The paths **Take it over and get it building.** Repository in your organisation. Node, Xcode and Android tooling pinned to versions that work. Accounts and keys moved or re-established. A build that runs on a clean machine for both platforms, then through the test tracks. This is the first stage, always. **Upgrade in stages.** React Native version by version with the official upgrade helper, native modules replaced where abandoned, Expo SDK brought current if it's an Expo app. Each step builds and ships to a test group before the next. **Rebuild in Flutter.** When the codebase is small and the upgrade would touch most of it anyway, or when the native modules can't be replaced. The backend and the design carry across. We build in Flutter, so this is a path we'd take ourselves, and the assessment says whether it's cheaper than the upgrade for your app. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) gets the app building, audits the modules and the accounts, and prices each path as a fixed number. ## Your data Usually behind an API or in Firebase, and it stays where it is, in an account you own. Nothing reaches your users until it has proven itself somewhere else: a build tested against a staging backend, released to a test group through TestFlight and the Play internal track, then to the store. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a React Native app it gets the project building in a clean environment, audits the native modules and the accounts, and prices the takeover and the upgrade as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting Two dates that have already passed: Xcode 26 for the App Store since April 2026, Android 16 targeting for Google Play from August 2026. An app that can't meet them can't ship a fix. After that: an operating system update that breaks something in the app and no way to respond, a lost keystore, a lapsed developer account, and modules whose vulnerabilities nobody is patching. ## How we approach it Keys and accounts first, then a build, then stages. Marc Allington builds mobile apps in Flutter and has taken over React Native codebases, so the trade-off between upgrading and rebuilding is one we make on evidence rather than preference. Everything we build runs in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a React Native takeover | Check | Why it matters | |---|---| | React Native version, Expo or bare, and whether it builds on a clean machine | Sets the upgrade distance and the first failure. | | Native modules: which, which are abandoned, which work with the new architecture | The upgrade's real cost. | | Apple Developer account, certificates, profiles: whose name, do they exist? | Without them no iOS build ships. | | Google Play account, upload key, Play App Signing: whose name, is the key findable? | A lost key without Play App Signing means a new listing. | | Backend: API or Firebase, in whose account | The data and the notifications live here. | | Store status: last release, current targets, pending rejections | How far from shippable it is today. | | Push, analytics, crash reporting, third-party SDKs and their keys | Each is a dependency and a credential. | | Tests and CI | Usually none. The safety net comes before the first upgrade step. | Each answer goes into the report with its stage and a fixed price. ## Questions Q: Why won't our React Native app build? A: Usually tooling. The agency's machine had the right Node, Xcode and Android versions and yours doesn't, and the project pins none of them. Getting it building on a clean machine with pinned versions is the first job and tells us everything else. Q: We don't have the Android keystore. Is the app lost? A: If Play App Signing was enabled, no: Google holds the signing key and the upload key can be reset. If it wasn't, the existing listing can't be updated and a new listing is needed. Establishing which is the first thing we do. Q: Would you rebuild it in Flutter? A: Only if the assessment shows it's cheaper than upgrading, which happens when the app is small or its native modules can't be replaced. We build in Flutter ourselves, so it's a real option, not a sales pitch. Q: It's an Expo app. Does that help? A: Usually, yes. Expo handles a lot of the native tooling, and bringing an old Expo SDK current is a known path. Old Expo apps that ejected are the harder case. Q: How long until we can ship an update? A: It depends on how far the versions have drifted and whether the keys exist, which the assessment measures. The shape is the usual one: a build in the test tracks within about six weeks, then upgrade stages, each priced before you commit. --- # Sage integrations URL: https://www.solvewithsoftware.com/modernise/sage-integrations Title: Sage Integration Modernisation Description: The Sage 50 or 200 link is often the part nobody understands. Mapped, rebuilt on the route Sage supports, and reconciled first. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over the integrations between business systems and Sage: the invoice posting, the customer sync, the nightly export that a VB6, Access or .NET system has been feeding into Sage 50 or Sage 200 for years. We map every field that crosses, rebuild the link on the route Sage supports for the product you're on, run the old and new links side by side, and reconcile the postings in Sage before anything switches. It's priced as a fixed stage from the assessment. ## Why the Sage link is where modernisation gets stuck Most business systems we take over talk to Sage somewhere. Sales invoices post to the ledger overnight. Customers created in the system appear in Sage. A stock adjustment in Sage comes back the other way. The integration was written once, years ago, against the Sage version of the day, by the person who wrote the rest of the system, and it has been working since. Finance depends on it every morning. That's why it holds everything else still. The link uses Sage Data Objects or an ODBC connection nobody has documented. It runs on one machine, because Sage 50 keeps its data in files on a Windows machine or server and the integration has to be there or on the same network. It breaks whenever Sage is upgraded, because the SDO version has to match the installed Sage 50 exactly, and then someone has to remember how it was installed. Moving the system to the web, or to a new server, or to a developer who isn't the original one, means touching the Sage link, and nobody wants to. ## How Sage can be integrated with today It depends on which Sage you're on, because the routes differ by product. | Product | The supported route | What that means | |---|---|---| | Sage 50 Accounts (UK) | Sage Data Objects (SDO), a COM SDK for members of the Sage Developer Programme. No REST API. | The integrating program runs on the Sage machine or its network as a 32-bit process, version-matched to Sage 50. Reading via ODBC works but is unsupported and read-only, and fields change between versions. Import files are the other route. | | Sage 200 Standard and Professional | A REST API, authenticated with Sage ID. | Integration can run anywhere, including a cloud-hosted system. This is the route we build to. | | Sage Accounting (Business Cloud) | A REST API, currently v3.1, with OAuth. | The same shape as Xero or QuickBooks Online: a hosted system talks to it directly. | | Sage Intacct | An API for partners and customers. | Integration runs anywhere; the data model is different from Sage 50 and the mapping is redone. | Sage 50 is the one that shapes a modernisation. A system moving to the web can't talk to Sage 50 from the cloud on its own; it needs a small agent on the Sage side, or the postings go through Sage's import files, or the integration becomes the reason to look at Sage 200 or Sage Accounting. All three are legitimate. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) says which fits. ## What we do with an existing Sage integration 1. **Map every crossing.** Which records go in which direction, when, what triggers them, and what happens when Sage is closed, locked or being backed up. The assessment produces this from the code and from watching a day's run. 2. **Reproduce it in a test company.** A restored Sage backup in a separate company, a copy of the system's database, and the existing integration run against both, so we have a known-good result to compare with. 3. **Rebuild the link on the supported route.** SDO done properly for Sage 50, with the version dependency isolated in one place; REST for Sage 200 or Sage Accounting. 4. **Run old and new side by side** against the test company, and reconcile: every posting, every customer, every balance, matched. 5. **Switch**, with the old link kept and switchable back until finance has closed a period on the new one. The mapping from step one is the document that survives everything after it, including a later move to a different Sage product. ## If you're moving off Sage 50 as well To Sage 200, Sage Accounting, Intacct or Xero. The integration is rebuilt against a different API and the field mapping is redone, because the products don't share a data model. The plan is the same as above with one more rule: never move Sage and the system in the same period. Move the system with the Sage 50 link kept working, close a period, then move Sage with the system already stable, or the other way round. Doing both at once leaves finance with nothing to reconcile against. ## Your data Sage is the ledger, so nothing posts to live Sage until the same postings have been reconciled in a test company. Every change to the integration is tested against a restored Sage backup and a copy of the system's data, then run in staging with the postings matched line by line, before it connects to live. The old link stays switchable back until a period has been closed on the new one. ## Can this be done gradually? **Yes, and it's usually one crossing at a time.** Invoices first, because that's the one finance watches; customers and suppliers next; stock or payments last. Each runs side by side and reconciles before the next moves, and the whole exercise can pause between stages with everything still working. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Sage integration it maps every crossing, confirms which Sage product and version you're on and which route it supports, and prices the rebuild as a fixed number, on its own or as a stage of a wider modernisation. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting Sage 50 gets a new version every year, and v34 is current. Each one has to be matched by the SDO the integration uses, so each upgrade is a chance for the postings to stop. Sage 50 has been a 64-bit application since v30, while the integration route stays 32-bit, which catches out anyone rebuilding the machine it runs on. And the person who knows how the link was installed is a single point of failure for the month-end. ## How we approach it Map it, reproduce it in a test company, rebuild it on the supported route, reconcile before switching. Marc Allington has built and maintained Sage integrations inside the VB, Access and .NET systems he's taken over, and builds on modern .NET now. Everything we build runs in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a Sage integration | Check | Why it matters | |---|---| | Which Sage product and version, and whether Remote Data Access is in use | Decides the route: SDO on the Sage side for Sage 50, REST for Sage 200 and Sage Accounting. | | How the existing link talks to Sage: SDO, ODBC, import files, or direct file access | ODBC and direct access are read-only and unsupported; anything writing that way is the first risk. | | Which machine it runs on, as which user, and who can rebuild that machine | The 32-bit SDO, the matching Sage version and the Sage login all live there. | | Every record type that crosses, in which direction, on what trigger | The mapping. It's the specification for the rebuild and the reconciliation. | | What happens when Sage is closed, locked or mid-backup | Where postings get lost or doubled today. | | Whether a Sage upgrade has broken it before, and how it was fixed | Tells us how the version dependency is handled, or isn't. | | Whether Sage itself is due to change: Sage 200, Sage Accounting, Xero | Changes the target API and the order of the plan. | | Test company: can a Sage backup be restored alongside live? | Without it there's no safe place to reconcile. | Each answer goes into the report with its consequence and a fixed price. ## Questions Q: Our Sage integration stopped working after a Sage upgrade. Why? A: Almost always the SDO version. The Sage Data Objects the integration uses have to match the installed Sage 50 version exactly, so each Sage upgrade needs the matching SDO installed on the integration machine. A rebuilt link isolates that dependency so the fix is a known step rather than a search. Q: Is it true Sage 50 has no API? A: No REST API, yes. The supported way to write to Sage 50 Accounts is the SDO, a COM SDK available through the Sage Developer Programme. ODBC reads the data but isn't supported for writing, and import files cover simple cases. Sage 200 and Sage Accounting have REST APIs. Q: Can a web-based system talk to our Sage 50? A: Not directly, because Sage 50 keeps its data in files on your Windows machine or server. It works with a small agent on the Sage side that the web system talks to, or through import files. If the business is moving to the web anyway, that's the point to look at Sage 200 or Sage Accounting, which the web system can talk to directly. Q: We're moving from Sage to Xero. Does the integration survive? A: The mapping survives; the code doesn't, because Xero is a different API with a different data model. The rebuild is planned around the move, and the rule is one change at a time: move the system or move the ledger, close a period, then the other. Q: How long does rebuilding a Sage integration take? A: It depends on how many record types cross and in how many directions, which the assessment counts. Invoices posting from the new link and reconciled in a test company is usually the first milestone, within about six weeks, then one crossing at a time, each priced before you commit. --- # SharePoint applications after end of support URL: https://www.solvewithsoftware.com/modernise/sharepoint Title: SharePoint 2013 to 2019 Modernisation Description: SharePoint 2016 and 2019 are out of support, InfoPath retired. Documents to Microsoft 365 once, then the applications rebuilt. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over the business applications that grew inside on-premises SharePoint: lists used as databases, InfoPath forms, SharePoint Designer and 2013 workflows, custom web parts and farm solutions. SharePoint 2016 and 2019 have been out of support since 14 July 2026, and Microsoft has retired the forms and workflow technology those applications depend on. We inventory what's there, move the document side to Microsoft 365 or Subscription Edition, and rebuild the processes that outgrew a list as applications you own, one at a time, on a fixed price from the assessment. ## Where SharePoint on-premises stands The dates have arrived. SharePoint Server 2013 went out of support in April 2023; 2016 and 2019 followed on 14 July 2026. A farm on any of them gets no security fixes. The applications inside it are on their own timetable. In Microsoft 365, SharePoint 2013 workflows stopped on 2 April 2026, and InfoPath Forms Services was retired on 14 July 2026, with new or changed forms blocked from May. On an on-premises farm those forms and workflows keep running, unsupported, for as long as the farm does. So the choice isn't whether to move them. It's whether they become Power Apps and Power Automate flows in Microsoft 365, or an application of their own. SharePoint Server Subscription Edition is Microsoft's on-premises successor, with no fixed end date but the same legacy features being retired over time. It's a home for the documents, not for the applications. ## What SharePoint became in most businesses A document store, which it's good at, and then a place to build things because it was there. The pattern is the same everywhere: - **Lists as databases.** Customers, jobs, assets, in lists with lookups between them, past the point where a list copes. - **InfoPath forms** for data entry, with rules in the form. - **SharePoint Designer or 2013 workflows** for approvals and notifications, built by someone who's left. - **Custom code.** Web parts, event receivers, timer jobs, farm solutions, written against a SharePoint version that's gone. - **Integrations** with the line-of-business systems, often through the same custom code. The document store moves to Microsoft 365 with tooling. The applications don't, and they're where the business runs. ## Three destinations, decided per application **Microsoft 365, with Power Apps and Power Automate.** Microsoft's route for forms and approvals. Right for small, document-centred processes that stay close to SharePoint. The Power Apps page (https://www.solvewithsoftware.com/rescue/power-apps) covers what happens when that route is pushed past its limits. **An application you own.** For the lists that became databases and the workflows that became the business process. A database, screens and rules in one place, with documents still in SharePoint or Microsoft 365 and linked. No delegation limits, no per-user premium licence, and customers or suppliers can be given access. **Subscription Edition on-premises.** Where the data has to stay on-site, for the documents and for the applications that haven't moved yet. It buys time, and the retirements follow it. The assessment sorts every application into one of the three from evidence, and the plan does the document migration once and the applications one at a time. ## The staged path 1. **Inventory.** Every site, list, form, workflow and piece of custom code, with its owner, its last use and what depends on it. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) produces this from the farm, not from memory. 2. **Classify.** Documents, small processes, applications. Three destinations. 3. **Move the documents** to Microsoft 365 or Subscription Edition, with the migration tooling, once. 4. **Rebuild the applications**, one at a time, in order of risk: the list nearest its limits or the workflow nobody can change first. Each runs in staging on migrated data, reconciled, then switches, with the SharePoint version read-only behind it. 5. **Rebuild the small processes** in Power Apps and Power Automate where that's the fit, or fold them into the application. 6. **Decommission the farm** when the last application has moved. Each stage has its own fixed price, and each ends with something working and off the old farm. ## Your data Lists export cleanly, with their lookups mapped to relationships. Documents move with their metadata and versions. Neither meets a change until the change has proven itself somewhere else: a migration tested against a copy in a test environment, then run in staging with counts and a sample reconciled, before anything switches. The SharePoint site stays read-only alongside until you're confident. ## Can this be done gradually? **Yes, and for a farm with several applications it's the only safe way.** Documents once, then one application at a time, with the rest of SharePoint untouched until their turn. Stop after any stage and keep everything. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a SharePoint farm it produces the inventory, sorts every application into its destination, and prices the document move and each application as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting The farm is unpatched now, and it's usually the one internet-facing thing in the estate that the IT team can't upgrade. The workflows and forms have no supported replacement path on the farm, so each change to a process is done by hand or not at all. And the person who built the workflows left with the only description of how the business approves things. ## How we approach it Inventory, classify, documents once, applications one at a time. Marc Allington has built on SharePoint on-premises and builds on the .NET and web stacks that SharePoint applications move to. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a SharePoint farm | Check | Why it matters | |---|---| | Version and patch level, farm topology, and what else runs on those servers | Sets the urgency and whether the farm can stay long enough to migrate from. | | Every list over a few thousand items, and every lookup between lists | The lists that became databases, and the relationships a rebuild has to keep. | | InfoPath forms: how many, which have rules or code, and which are still used | Each is a form to rebuild, in Power Apps or in the application. | | Workflows: Designer, 2013, Nintex or K2, and what each approves or notifies | The business process, usually undocumented anywhere else. | | Custom code: web parts, event receivers, timer jobs, farm solutions, and whether the source exists | Farm solutions have no place in Microsoft 365; each is a rebuild or a retirement. | | Integrations with line-of-business systems | Every one has a caller to re-point. | | Identity: on-premises AD, ADFS, or already synced to Entra | Decides how users reach the new home. | | Documents: volume, versions, metadata, permissions that matter | Sizes the document migration and the tooling. | Each answer goes into the report with its destination, its consequence and a fixed price. ## Questions Q: Can't we move everything to SharePoint Online? A: The documents, yes, with tooling. The applications don't move: InfoPath and 2013 workflows are retired in Microsoft 365, and farm solutions have no equivalent. Each application is rebuilt, in Power Apps and Power Automate or as an application of its own. Q: Our InfoPath forms still work. Do we have to replace them? A: On an on-premises farm they keep rendering, unsupported. In Microsoft 365 they were retired on 14 July 2026. Any move off the farm replaces them, and the assessment counts them and reads the rules inside each one. Q: What about SharePoint Server Subscription Edition? A: Microsoft's on-premises successor, with no fixed end date. It's the right home for documents that must stay on-site and it buys time for applications that haven't moved. The same legacy features are being retired from it, so it's a step, not a destination for the applications. Q: Power Apps or a custom application? A: Power Apps for small processes that stay close to SharePoint and Microsoft 365. A custom application when the list has become a database, the process has rules the platform can't express, or outside users need access. The assessment decides per application from the inventory. Q: How long does moving off a SharePoint farm take? A: It depends on how many applications the inventory finds. The shape is the usual one: documents moved and the first application running in staging within about six weeks, then one application at a time, each priced before you commit. --- # SQL Server modernisation and cloud migration URL: https://www.solvewithsoftware.com/modernise/sql-server Title: SQL Server Upgrade and Migration Description: SQL Server 2016 is out of support, 2017 goes in October 2027. Upgrade or Azure, and how to move a database without breaking its apps. From £395 + VAT. Last reviewed: 2026-09-04 SQL Server 2016 went out of support on 14 July 2026, 2017 follows on 12 October 2027, and the Windows Server most of them run on ends in January 2027. Solve With Software moves the database rather than only the version number: an in-place upgrade to a supported release, a move to Azure SQL where the case is real, or paid extended updates as a bridge while the applications on top are dealt with. Every application that reads the database is found first, and the move is rehearsed in staging with the data reconciled before anything switches. ## Where the versions stand The dates are published, and two of them have already arrived. | Version | Extended support ends | Notes | |---|---|---| | SQL Server 2012 and earlier | Passed | Out of support for years; paid updates have also ended | | SQL Server 2014 | 9 July 2024 | Passed | | SQL Server 2016 | 14 July 2026 | Passed. Paid Extended Security Updates run to July 2029 | | SQL Server 2017 | 12 October 2027 | | | SQL Server 2019 | 8 January 2030 | | | SQL Server 2022 | January 2033 | | | SQL Server 2025 | Released November 2025 | Current | Out of support means no security patches. A database server that's reachable from the network and no longer patched is the kind of risk that doesn't announce itself. The server underneath has its own date: Windows Server 2016 support ends in January 2027, and a SQL Server on it goes with the server. ## What we usually find A version chosen when the application was built and never revisited, because it worked. Compatibility level set for a version older than the one installed. Stored procedures that hold business rules nobody has read in years. SQL Server Agent jobs that run overnight and that only one person knows about. Linked servers to something that no longer exists. And three or four applications reading the database that weren't in the original list: a reporting tool such as SSRS (https://www.solvewithsoftware.com/modernise/ssrs), a spreadsheet with a live query, an integration someone set up in 2019. The database is usually fine. The problem is that nobody has a map of what depends on it, and upgrading a database without that map is how applications break on a Monday. ## The paths **Upgrade in place, or side by side, to a supported version.** SQL Server 2022 or 2025 on a supported Windows Server. The usual answer for a database that stays on your own infrastructure. Side by side (a new server, restore, test, cut over) is safer than in place, because the old server stays as the fallback. **Move to Azure SQL.** Azure SQL Managed Instance where the applications need SQL Agent jobs, linked servers and the rest of the full product; Azure SQL Database where they don't. The case is real when the server hardware is due for replacement anyway, when backups and patching are the thing nobody is doing, or when the business is moving other systems to the cloud. It's not automatically cheaper, and the assessment puts the numbers side by side rather than assuming. **Extended Security Updates as a bridge.** Paid, per core, and rising each year, but they buy time on 2016 while the applications on top are modernised. Sensible when the application is the real project and the database move is a stage of it, not the point. **Migrate to PostgreSQL.** Rarely worth it for an existing system, because every stored procedure and every application query has to change. It comes up when a rebuild is happening anyway and licensing is the driver. The assessment says whether it applies. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps what depends on the database and prices each path as a fixed number. ## How a database move works 1. **Find everything that reads it.** Applications, reports, spreadsheets, integrations, Agent jobs, linked servers, replication. This is most of the assessment and most of the risk. 2. **Check what the target rejects.** Deprecated features, compatibility level, collation, CLR assemblies, old drivers on the application side. SQL Server's own tooling reports most of it; a person reads the rest. 3. **Build the new server, or the Azure target, and restore a copy.** Run every application against the copy in a test environment. 4. **Rehearse the cutover in staging.** Restore, re-point each application, run the overnight jobs, run the reports, reconcile counts and totals against the old server. 5. **Cut over** at a quiet time, with the old server left intact and reachable as the fallback until you're confident. 6. **Retire the old server** and its Windows licence when the fallback is no longer needed. Downtime is the length of the final restore and re-pointing, which the rehearsal has measured. ## Your data It moves once, by backup and restore or by the Azure migration tooling, and it's reconciled on the other side: row counts, checksums, totals, and a sample of records compared. Nothing switches until the rehearsal in staging has shown the applications work against the new server. The old server stays as the fallback. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a SQL Server move it maps every dependency, checks the target's requirements, and prices the move as a fixed number, alongside the licence and hosting numbers for each path. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting Unpatched, and reachable. That's the whole risk of an out-of-support database server, and it applies to 2016 now. Cyber Essentials and insurance questionnaires ask about it. After that: the Windows Server date in January 2027, the application whose driver won't talk to a newer server, and the overnight job nobody documented, which is found on the day it doesn't run. ## How we approach it Map the dependencies, rehearse the move, keep the old server until the new one has proven itself. Marc Allington has run SQL Server under business systems since SQL Server 2000 and has moved them on-premises and to Azure. Everything we build runs on open, widely used technology, in your own accounts. ## The technical checklist for a SQL Server move | Check | Why it matters | |---|---| | Version, edition and compatibility level | Sets the support date and what the upgrade tooling will flag. | | Every application, report, spreadsheet and integration that connects | The dependency map. The ones not on the list are the ones that break. | | SQL Agent jobs, linked servers, replication, CLR | Each has to exist on the target, or be replaced. | | Drivers on the application side | Old OLE DB and ODBC drivers refuse newer servers or newer encryption. | | Backups: are they taken, and do they restore? | Tried, not assumed, before anything else. | | Server: Windows version and what else runs on it | Windows Server 2016 goes in January 2027; other services on the same box shape the plan. | | Data volume and the restore time | Sets the cutover window. | | Licensing: cores, CALs, Software Assurance | Decides whether Azure or a new on-premises licence is the cheaper path. | Each answer goes into the report with its consequence for each path and a fixed price. ## Questions Q: We're on SQL Server 2016. How urgent is this? A: Support ended on 14 July 2026, so it's unpatched now. Paid Extended Security Updates run to 2029 and are a reasonable bridge if the applications on top need work first. Doing nothing isn't a bridge. Q: Will upgrading break our applications? A: Only the ones nobody mapped. The move is rehearsed in staging with every application re-pointed and every job run against a copy, so what would break is found before the day. The old server stays as the fallback. Q: Should we move to Azure? A: Sometimes. It's the right answer when the hardware is due anyway, when nobody is patching or backing up the server, or when the rest of your systems are going that way. It's not automatically cheaper, and the assessment puts the numbers side by side. Q: How much downtime? A: The length of the final restore and re-pointing, which the rehearsal measures. For most business systems that's a quiet evening, with the old server intact if anything is wrong. Q: Our application is old too. Which first? A: Usually the database, because it's the shared foundation and the move is contained. Then the application, in stages, against a database that's now supported. The assessment sets the order for your case. --- # SSRS migration and replacement URL: https://www.solvewithsoftware.com/modernise/ssrs Title: SSRS Migration After SQL Server 2025 Description: SSRS 2022 is the last version, supported to 2033. Power BI Report Server takes over on premises. Every report moved, RDLC included. From £395 + VAT. Last reviewed: 2026-09-04 SQL Server Reporting Services is the reporting layer under a large share of the business systems built on SQL Server, and Microsoft announced in June 2025 that SSRS 2022 is the last version. It stays supported until 11 January 2033, Power BI Report Server is the on-premises replacement, and SQL Server 2025 Express ships with no reporting at all. Solve With Software inventories every RDL and RDLC report, extracts what each one does, then moves the reporting layer to Power BI Report Server, into the modernised application, or both, with each report matched against the old output before it switches. ## Where SSRS stands Finished, on a long fuse. On 19 June 2025 Microsoft announced that SQL Server 2025 would ship without Reporting Services. SSRS 2022 is the last release. It gets security updates and support until 11 January 2033, in line with SQL Server 2022, and it can keep its ReportServer database on a newer database engine, so nothing has to move by a deadline. The earlier versions follow their SQL Server. SSRS 2016 went out of support on 14 July 2026, 2017 ends on 12 October 2027 and 2019 on 8 January 2030. What replaces it is Power BI Report Server, which runs the same RDL reports and adds interactive Power BI reports. A SQL Server 2025 Standard or Enterprise key installs it; on older versions it needs Enterprise edition with Software Assurance. SQL Server 2025 Express, the edition a lot of small systems were built on, has no Reporting Services and no Report Server option. ## Server reports, or reports inside the application? **Two different jobs, and most legacy systems have both.** Server reports are the .rdl files on a report server: the Report Manager page the office bookmarks, the subscription that emails the sales figures at seven each morning, the exports finance runs at month end. They live outside the application and can move on their own. Embedded reports are the .rdlc files inside a WinForms or ASP.NET Web Forms application, rendered by Microsoft's ReportViewer control. They move when the application does, and that is where the difficulty is. The ReportViewer control was built for .NET Framework and was never ported to ASP.NET Core, so a modernised web application needs a different way to render them. The ports that exist are community-maintained, not Microsoft's. ## What moving off SSRS involves 1. **Inventory.** Every .rdl on the server and every .rdlc in the source, who runs it, how often, which subscriptions fire and where they deliver. The ReportServer database and its subscription tables tell most of it. Half the reports are usually dead. The ones that remain are the specification. 2. **Extract what each report does.** The dataset queries and stored procedures, the parameters, the expressions, the grouping and totals, the layout. Expressions are where the business rules hide. 3. **Choose the reporting layer.** Power BI Report Server where the reports are server reports and the licence covers it. Reports built into the modernised application where the application produces them for its users. A reporting product where the business needs ad-hoc analysis. Sometimes all three. 4. **Move or rebuild each report** and run it side by side with the SSRS version on the same data. Totals, row counts, and the layout the finance team recognises. A report doesn't switch until it matches. 5. **Retire the old server** when the last subscription has moved. Each report is a small stage of its own, which is why the work can be priced as a fixed number and done in the order the business cares about. ## Do we have to move at all? **Not by a deadline, and sometimes not at all.** SSRS 2022 is supported for six more years, so a stable set of server reports on a supported SQL Server can stay where it is while the application in front of it is modernised. The case for moving is one of three things. A SQL Server upgrade that takes the report server with it. An application modernisation that leaves the embedded reports with nothing to render them. Or the Express edition, which loses reporting with SQL Server 2025. The assessment establishes which applies and what is worth doing now. ## Your data Untouched. Reports read; they don't change anything. The moved or rebuilt reports run against the same database as the SSRS ones, side by side, until each matches. Where the new reporting layer needs views or a reporting database of its own, they are built and tested on a copy, then in staging alongside live, before anything connects to the live server. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For SSRS it inventories the report server and the application's RDLC files, identifies which reports are alive, extracts what a sample of them do, and prices the move report by report as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting A report server on SQL Server 2016 or 2017, with the support date passed or passing. An application modernisation that reaches the reports last and finds they can't be rendered on the new platform. Subscriptions nobody remembers setting up, still emailing figures from a server that is about to go. And the rules that live only in report expressions being lost because nobody inventoried them. ## How we approach it Inventory first, then match every report before switching it. Marc Allington has built and replaced SSRS reporting on the .NET and SQL Server systems it usually sits behind, server reports and embedded RDLC alike, so the ReportServer database, the subscriptions and the ReportViewer's habits are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for an SSRS migration | Check | Why it matters | |---|---| | SSRS version and edition, and the SQL Server it runs on | Sets the support date and whether Power BI Report Server is licensed. | | Every .rdl on the server: who runs it, how often, and from where | Dead reports don't move; live ones are the specification. | | Every .rdlc in the application source, and the ReportViewer version | Embedded reports move with the application and need a renderer on the new platform. | | Subscriptions, schedules and delivery targets | The reports nobody runs by hand, and the first thing missed after a move. | | Datasets: shared data sources, stored procedures, embedded SQL | Some reports read from objects the main system forgot; each has to be found. | | Expressions, custom code and parameters | Where the business rules hide. Each is extracted and written down. | | Output formats: PDF, Excel, CSV, print | Each is a requirement of the new reporting layer. | | Express edition | No Reporting Services in SQL Server 2025 and no Report Server option; decides the route. | Each answer goes into the report with a fixed price per report. ## Questions Q: Is SSRS end of life? A: SSRS 2022 is the last version. It is supported until 11 January 2033, so nothing switches off soon, but there will be no SSRS for SQL Server 2025 or later. Power BI Report Server is the on-premises replacement. Q: Do our existing RDL reports work on Power BI Report Server? A: Yes. Microsoft states that existing RDL reports are fully compatible, and publishes a guide for moving a report server across. What takes the time is proving each report still produces the same output, which is why we run them side by side. Q: What about the reports built into our application? A: RDLC reports rendered by the ReportViewer control move when the application does. There is no Microsoft ReportViewer for ASP.NET Core, so a modernised web application needs a different reporting layer. The assessment sets that out report by report. Q: We're on SQL Server Express. What happens to our reports? A: SQL Server 2025 Express has no Reporting Services and no Power BI Report Server option. An existing SSRS install on Express keeps running for as long as its SQL Server is supported. After that the reports need a new home, usually inside the application. Q: Can you move the reports without touching the application? A: If they are server reports, yes: the report server can move or be rebuilt on its own. Embedded reports are part of the application and move with it, usually as the last stage. The assessment establishes which you have. --- # VB6 modernisation and migration URL: https://www.solvewithsoftware.com/modernise/vb6 Title: VB6 Modernisation and Migration Description: VB6 still runs UK businesses. We take a Visual Basic 6 system over, keep it running, and migrate it to .NET or the web in stages. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over Visual Basic 6 applications that still run a business, stabilises them, and migrates them in stages to .NET or the web. The VB6 runtime still works on Windows 11, so there's rarely an emergency, but the IDE has been unsupported since 2008, the developers are retiring, and every year the migration gets harder. The assessment tells you which of three paths fits your system, with a fixed price on each. ## Where VB6 stands in 2026 The runtime is fine. Microsoft ships the VB6 runtime with Windows 11 and has said it will support it for the life of the operating system, so a compiled VB6 program usually installs and runs on a new PC. That's why so many are still going. The tooling around it is a different matter. The IDE stopped being supported in 2008 and doesn't install on a modern machine without workarounds. The database drivers it was written against, Jet and old versions of ADO, are the usual point of failure. Third-party controls, the OCX and ActiveX components most VB6 apps lean on, come from companies that no longer exist. And the people who wrote VB6 for a living are retiring. So the system keeps running, right up until something around it moves: a Windows update that breaks a control, a SQL Server upgrade the driver can't talk to, a report engine that won't register on a new PC, or the one developer who knew it stepping back. ## What we usually find inside Twenty years of business rules, and they're the valuable part. Most VB6 business systems were built by one or two people over a long time. The forms are dense, the code behind them does the work, and the rules the business depends on live in event handlers rather than anywhere you'd look for them. There's often a Jet or Access back end that later moved to SQL Server, a Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports) layer, an export to Sage (https://www.solvewithsoftware.com/modernise/sage-integrations), and a set of workarounds the office has learned. None of that is a reason to throw it away. It's the specification for whatever comes next, and it's the thing a rewrite from scratch loses first. ## The three paths **Stabilise and keep it running. (https://www.solvewithsoftware.com/legacy-software-support)** Source code into version control, if it can be found. A build that works on a current machine, with the controls it needs recorded and backed up. The database moved off Jet onto SQL Server if it isn't already, with the drivers updated. A test environment. This is the right first stage for almost every VB6 system, whatever comes after, and for some it's the whole answer for years. **Migrate to .NET in stages.** Modern screens over the same data, one process at a time. VB6 and .NET can run side by side against the same SQL Server database, so a new .NET screen can replace one VB6 form while the rest of the system carries on. The business rules move across as they're understood, with the old form kept until the new one has proven itself. This is the path most systems take. **Replace with a web application.** When the business needs the system outside the office, on phones, or shared with customers, the target is the web rather than the desktop. Same staged approach: the web version grows alongside the VB6 system on the same data, process by process. Automatic conversion tools exist that turn VB6 into VB.NET or C#. They can help with reading an old system. As a migration, they produce code that compiles and then gets rewritten, because it carries every VB6 habit into a language that doesn't want them. ## What happens to the data It stays where it is, or moves once, carefully. If the back end is Jet or Access, the first stage moves it to SQL Server, which both the VB6 system and anything new can share. If it's already SQL Server, nothing moves at all until a process is migrated, and then only that process's data is touched. Nothing meets a change until the change has proven itself somewhere else: built and tested on a copy in a test environment, then run in staging alongside the live system with the data reconciled there. Only when the tests have shown it's safe does anything connect to live, and the VB6 system stays available as a fallback. ## Can this be done gradually? **Yes, and it should be.** The reason VB6 migrations fail is the big-bang rewrite (https://www.solvewithsoftware.com/problems/too-risky-to-change): a long build of a replacement in parallel while the business changes underneath it, then a cutover weekend that goes wrong. Staged migration means one process at a time, each one live and paid for before the next starts, and the option to stop at any stage with a system that's better than it was. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a VB6 system that means reading the code and the database, finding out whether the source and the controls exist, and pricing each of the three paths as a fixed number. Each stage after that is priced before you commit to it. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The risks of waiting Two that are dated and one that isn't. Windows Server 2016 support ends in January 2027, and SQL Server 2016 security updates ended in July 2026 for most licence holders; a VB6 system on either loses its security updates with them. The undated risk is people. Every year fewer developers can read VB6 fluently, and the one who built yours will retire. The runtime working on Windows 11 buys time. It doesn't replace the people who understood the code. ## How we approach it Marc Allington built business systems in VB before .NET existed and has migrated them since, so a VB6 form is familiar ground rather than archaeology. The approach is the same as every takeover: understand, stabilise, then modernise one safe step at a time, on open technology in your own accounts, with full source code and ownership transferring to you on final payment. ## The technical checklist for a VB6 takeover What the assessment establishes for a VB6 system, and why each item matters: | Check | Why it matters | |---|---| | Is the source code available, and does it match the running program? | Without source, the options narrow to keep-running or replace. A source tree that's older than the compiled program is common and has to be reconciled. | | Which third-party controls does it use, and do we have the files and licences? | Missing OCX and ActiveX components are the usual reason a VB6 app won't install on a new PC. | | What is the back end: Jet, Access, SQL Server, something else? | Jet is the first thing to move. SQL Server can be shared with a .NET or web replacement from day one. | | Which data access layer: DAO, ADO, RDO? | Determines which drivers have to work on a modern machine, and how hard the database move is. | | Where do the business rules live? | Usually in form event handlers. Mapping them is most of the migration effort, whichever path is chosen. | | What else depends on it? | Reports, exports, scheduled jobs, spreadsheets, other systems reading its database. | | Can it be built and run in a test environment? | If not, that's the first stage, before anything else changes. | Each answer goes into the report with its consequence for the three paths and a fixed price for each. ## Questions Q: Will our VB6 application keep running on Windows 11? A: Usually, yes. The runtime is supported for the life of Windows 11. What breaks is more often a third-party control, a database driver or a report engine. The assessment checks those specifically. Q: We don't have the VB6 source code. What then? A: It happens often. The compiled program and the database still tell most of the story, and the choice becomes keep it running while a replacement is built alongside it, sharing the same data. The assessment establishes what you have before anyone spends money on either. Q: Can't a tool just convert it to .NET? A: Tools exist. They produce code that compiles and then gets rewritten, because it carries every VB6 habit into a language that doesn't want them. They're useful for reading an old system, not for replacing it. Q: How long does a VB6 migration take? A: It depends on how many processes the system runs and how tangled the rules are, which is what the assessment measures. What we can say is the shape: a first stage with something working within about six weeks, then one process at a time, each priced before you commit. Q: Should the replacement be desktop or web? A: Web, if anyone needs it outside the office or on a phone. Desktop .NET, if it's a heads-down back-office tool and the users are at their desks. Sometimes both, sharing one database. The assessment recommends one and prices it. --- # We have no documentation for our software URL: https://www.solvewithsoftware.com/problems/no-documentation Title: No Documentation for Your Software? Description: No documentation and the developer has gone. We work out what the system does from the code, the database and its users. From £395 + VAT. Last reviewed: 2026-09-04 Most of the business systems Solve With Software takes over have no documentation, or documentation that describes a version from years ago. It means the assessment spends more time inside the system, working out what it does from the code, the database and the people who use it, and writing that down. Once the report exists, the system is documented, and the knowledge stops depending on who's in the building. ## What no documentation usually means It rarely means nobody knows anything. It means the knowledge is spread out: some in the code, some in the database, most of it with the three people who've used the system longest, and a bit on a printout by the despatch desk. The developer who could have written it down was busy building it, and then they left. That's how most of the bespoke systems we take over arrive. Where it bites: - You can't brief another developer, so every quote you get is a guess. - A supplier proposes a full rewrite because they can't see inside the thing they'd be replacing. - A new starter takes months to learn the system, and learns the workarounds along with it. - Nobody changes anything, because nobody knows what else a change would touch (https://www.solvewithsoftware.com/problems/too-risky-to-change). ## How we work out what it does Four sources, cross-checked against each other. **The code.** Even without a comment in it, code says what it does. We read it and map the screens to the tables, and the tables to the processes. Where there's no source code at all, the compiled program and the database still tell most of the story. **The database.** The schema is the most honest document a system has. Tables, relationships, the columns nobody uses any more, the one that changed meaning in 2014 and never got renamed. **The people.** We sit with the people who use the system and watch the work go through it, and we ask about every workaround. The workarounds are where the undocumented rules live. **The paperwork around it.** The spreadsheets, the printouts, the email templates, the link to Sage. Anything that goes in or comes out. Then we write it down: what the system does, what depends on it and what it depends on. That document is section two of the assessment report, and the report is yours. ## Do we need to find the original developer? **No. Helpful if you can, not required.** An hour with them fills gaps faster, but most takeovers happen without the original developer, because they've usually retired, moved on or stopped answering. The code, the database and your team carry enough of the story between them. ## Can you take it over without the source code? **Usually. It's a constraint, not a dead end.** Sometimes the code can be recovered from the installed system or an old backup. Sometimes the right answer is to keep the running system supported while a replacement is built alongside it, sharing the same data, so nothing is lost while the new one takes over one process at a time. The assessment establishes which situation you're in before anyone spends money on either. ## What it costs The legacy system assessment (https://www.solvewithsoftware.com/legacy-system-assessment) is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. An undocumented system needs more time inside it than a documented one, and the price reflects that, stated up front rather than discovered later. Everything after the assessment is priced by the report: a fixed price for each option. ## Your data Nothing changes during discovery. We read; we don't change. When work follows, it never touches your live data until it has proven itself somewhere else: built and tested against a copy in a test environment, then run in staging alongside the live system with the data migrated, checked and reconciled there first. Only when the tests have shown it's safe does anything connect to live, and the old system stays available as a fallback until you're confident. ## The risk of leaving it undocumented Every month without documentation is a month the business runs on memory. People leave, and memory goes with them. A rewrite quoted without a map of the rules (https://www.solvewithsoftware.com/problems/replace-or-modernise) loses the rules, and they get rediscovered in production, one complaint at a time. The documentation is also what makes a fixed price possible. Nobody can price what they can't see. ## How we approach it Understand first, then stabilise, then modernise one safe step at a time. Marc Allington leads the discovery and the work that follows. He has built business systems in VB, Access, SQL Server and .NET as well as on the web and in the cloud, so the code we're reading is usually a kind we've written ourselves. Everything we build afterwards runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment, and it comes documented. ## How discovery works, step by step The same method for every undocumented system, whether it's VB6 or Node: 1. **Inventory.** Every screen, report, scheduled job, integration and file the system touches. Output: a system map. 2. **Data model.** Every table and relationship, what each holds, and which screens write to it. Output: a data dictionary. 3. **Walk-throughs.** Each main process followed end to end with the person who does it, workarounds included. Output: process notes. 4. **Code reading.** The screens and processes matched to the code, and anything the code does that nobody mentioned flagged. Output: the hidden rules. 5. **Environment.** Hosting, backups, source control, licences, and the support status of each, with dates. Output: the technical state and the risk register. Each source is checked against the others. A table with no screen that writes to it, a screen nobody mentioned in a walk-through, a job that runs at 2am: each mismatch is a question, and we keep asking until the map closes. Anything still uncertain is stated as uncertain in the report. This becomes sections two, three and four of the assessment report. ## Questions Q: Will you need a lot of our team's time? A: Some, and it's the most valuable part. An hour or two with each person who uses the system most. They know the workarounds; we know how to turn them into a specification. Q: What if the code has no comments? A: Most doesn't. Code without comments still says what it does; it just doesn't say why. The why comes from the people and the data, which is what the walk-throughs are for. Q: Can you document it and leave it at that? A: Yes. The documentation is section two of the assessment report, and the report is yours whether or not any work follows. Take it to us, another developer, or nobody. Q: Our documentation exists but is out of date. Does that help? A: Yes. It tells us what the system was meant to do, which we compare with what it does now. The gap between the two is usually where the interesting rules live. Q: How do you know you've found everything? A: We cross-check the code, the database, the walk-throughs and the paperwork against each other, and every mismatch becomes a question. When the map closes, we stop. Anything we're still not sure of is written in the report as not sure, not glossed over. --- # Should we replace or modernise our system? URL: https://www.solvewithsoftware.com/problems/replace-or-modernise Title: Replace or Modernise Your System? Description: Keep, modernise in stages, or replace? The six questions we put to an ageing system, and why the hard part is already paid for. From £395 + VAT. Last reviewed: 2026-09-04 For most business systems, Solve With Software's answer is modernise in stages rather than replace, because the hard part, working out what the system needs to do, is already paid for. Your current system is a living specification. Replace it outright when the technology can't be carried forward at all. Keep it as it is when the business isn't held up by it. The assessment tells you which of the three you're looking at, with a fixed price on each. ## The three options **Keep it and support it.** The system does its job. The risks are known and manageable. The money is better spent elsewhere. Support (https://www.solvewithsoftware.com/legacy-software-support) means someone to call and a system made safe to change, and that can be the whole engagement. **Modernise it in stages.** The rules and the data are sound; the technology around them isn't. New screens over the same data, an API so it can talk to the tools you've bought since, AI where it pays back, one process at a time, alongside the live system (https://www.solvewithsoftware.com/problems/too-risky-to-change). This is the answer for most of the systems we see. **Replace it.** The technology can't be carried forward, or the business has changed so much that the system's model of it is wrong. Even then, replace alongside rather than all at once, with the data moved and reconciled before anything switches. ## Why the hard part is already paid for The most expensive part of any software project is working out what the system needs to do. You did that years ago. Your current system, for all its faults, is a living specification: it shows how your business runs, where the pain is, and what's missing. You also know what you'd change. Most businesses in this position have a list, written or not, of everything they've wished for since the system went in. That list is the specification a new project would otherwise spend weeks discovering. And your data comes with you. Years of customer records, job history and reporting move into whatever comes next. Nothing starts from a blank page. ## When replacing is the right call When the technology can't be carried forward. No source code and no way to recover it (https://www.solvewithsoftware.com/problems/no-documentation). A platform that's dead, with no path to a supported version. A hosted product you don't own and can't extend. A data model that's wrong for how the business works now, so that every change fights it. Even then, the safe way to replace is alongside: the new system grows next to the old one, sharing the same data, taking over one process at a time, with the old route open until you're confident. A big-bang cutover is a choice, and rarely a good one. ## When keeping it is the right call When it does its job, the risks can be managed with support, and the money would do more elsewhere. That happens, and when it does the report says so, with a price for supporting the system rather than changing it. ## Small systems count A system doesn't have to be big to be worth modernising. Smaller systems are often the quickest wins: faster to bring under test, cheaper to modernise, and just as much of a change for the people who use them every day. An Access database with six users can be the right first project. ## Your data It comes with you whichever option you choose, and it never meets a change until the change has proven itself somewhere else. We build and test against a copy in a test environment, then run the new piece in staging alongside the live system, migrating, checking and reconciling the data there first. Only when the tests have shown it's safe does anything connect to live, and the old system stays available as a fallback until you're confident. ## What it costs The decision starts with a free one-hour consultation and a legacy system assessment (https://www.solvewithsoftware.com/legacy-system-assessment) from £395 + VAT, with an exact price before you commit. The report puts a fixed price on each of the three options for your system, so you're choosing between real numbers. What drives those numbers (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it We'd rather carry your rules forward than rediscover them. Marc Allington leads every assessment and the work that follows. He has built business systems in VB, Access, SQL Server and .NET as well as on the web, in the cloud and with AI, which covers most of the systems this decision is about. Anything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## The six questions we put to every system The assessment answers each of these for your system, and the answers point at one of the three options. The report states which, and why. | Question | Points to keep | Points to modernise | Points to replace | |---|---|---|---| | Do you have the source code, or can it be recovered? | Yes | Yes | No, and it can't be recovered | | Is the platform still supported, and for how long? | Supported | End of support in sight | Dead, with no upgrade path | | Is the data model right for how the business works now? | Yes | Mostly, with known gaps | No, every change fights it | | Does the business still work the way the system assumes? | Yes | Largely | No | | Can it be changed safely, with tests and a staging environment? | Yes, or easily made so | Once a safety net is built | Not without rebuilding it | | What would one first stage be worth? | Little; it already works | A lot, and quickly | Only worth it as part of a replacement | Two or more answers in the right-hand column and replacement is on the table. Everything in the left-hand column and the recommendation is to support it. Most systems land in the middle. ## Questions Q: Isn't a rewrite cleaner? A: It's cleaner on a whiteboard. In practice a rewrite has to rediscover every rule the old system enforces, and the ones nobody wrote down get rediscovered in production. Staged modernisation carries the rules forward and replaces the technology underneath them. Q: Our system is an old off-the-shelf product. Can it be modernised? A: Sometimes not, if you don't own the code or the data model is locked away. Then the choice is replace, and the question becomes how to move the data and the process across safely. The assessment answers that too. Q: Our system is small. Is it worth it? A: Often more so. Smaller systems are the quickest wins: faster to bring under test, cheaper to modernise, and just as much of a change for the people who use them every day. Q: How do we know the decision is right? A: You don't have to take it on trust. The report puts a fixed price on each option and states the trade-offs, and it's yours to take to anyone. Q: What if we choose wrong? A: Stages protect you. A first stage is one process and one price. If it shows the system is better or worse than expected, the plan changes before the next stage, not after a year. --- # Our AI-built app has stalled URL: https://www.solvewithsoftware.com/problems/stalled-ai-built-app Title: Stalled AI-Built App? We Finish It Description: Built most of an app in Lovable, Replit, Cursor or Bubble and it stalled? What's recoverable, what isn't, and how we take one over. From £395 + VAT. Last reviewed: 2026-09-04 Solve With Software takes over apps that were mostly built with Lovable, Replit, Cursor, Bolt or Bubble and then stopped: the screens exist, the demo worked, and what remained was the foundations nobody had built. Most of what was built is recoverable, some of it is better replaced, and the assessment tells you which. Whatever we finish runs on open technology in your own accounts, so the code is yours and any developer can pick it up. ## How it usually happens Someone in the business, often the owner, built more of an app than anyone expected. The screens look right. The demo went well. Then it met real data and real users, and progress stopped. The tool didn't fail. It did what it's good at: getting a working-looking version in front of people quickly. What it doesn't do is the part that makes software safe to run a business on, and that part is where the prompts stop working and the developer who would have finished it isn't there. We treat these the way we treat a VB6 system whose developer retired (https://www.solvewithsoftware.com/modernise/vb6). Something exists, it does part of the job, and the business needs it to do all of it. ## What's usually recoverable More than people expect. - **The screens and the flow.** The tools are good at these, and they're the part your team has already reacted to. They're a specification, even if the code behind them is rewritten. - **The data model, mostly.** Tables and fields reflect what the business tracks. They usually need tightening, but they're a head start. - **The rules you already discovered.** Every place the app got something wrong and someone fixed it is a business rule written down in code. We keep those. - **The data itself.** If real records went in, they come out, and they move to whatever comes next. - **The code, when it's exportable.** Lovable, Replit, Cursor and Bolt produce ordinary React, Node or Python that can be moved to your own repository and hosting. That's the case we prefer. ## What usually isn't The parts that don't show in a demo. - **Security.** Login that anyone can bypass, API keys in the front end, no permissions between users, no rate limits. This is the most common and the most serious. - **Data integrity.** No transactions, so a failure halfway through an order leaves half an order. No constraints, so the same customer exists four times. - **Error handling.** It works when everything goes right. Real systems spend most of their effort on what happens when it doesn't. - **Multi-user behaviour.** Two people editing the same record at once, one of them wins, nobody is told. - **Deployment, backups and monitoring.** Often the app only runs inside the tool that built it, and nobody has tested restoring it. - **Integrations.** The link to Sage, Xero or the warehouse system was on the list and never got past a stub. If the app lives entirely inside a hosted builder like Bubble, add one more: you don't hold the code at all, and moving off the platform means rebuilding the parts that depend on it. ## Finish it or start again? **Usually finish, on open technology.** When the code is exportable and the data model is sound, the fastest route is to move it into your own repository, put the missing foundations under it (security, integrity, tests, deployment) and then complete the features in order of value. The screens your team already knows stay. Rebuild when the code can't be exported, when the security holes run through the whole structure, or when the data model would have to change so much that patching it costs more than replacing it. The general keep, modernise or replace (https://www.solvewithsoftware.com/problems/replace-or-modernise) reasoning applies here too. Even then the screens and the discovered rules carry across, so a rebuild starts with the specification already written. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) makes that call from the code and the data, and puts a fixed price on each option. ## By tool The shape of the takeover depends on what the tool lets you keep, so each has its own page: - Lovable (https://www.solvewithsoftware.com/rescue/lovable): real code with GitHub sync; the backend often lives in Lovable Cloud. - Replit (https://www.solvewithsoftware.com/rescue/replit): the code exports; the database, secrets and hosting stay behind. - Bolt (https://www.solvewithsoftware.com/rescue/bolt): a clean front end; the back end and the hosting usually don't exist yet. - v0 (https://www.solvewithsoftware.com/rescue/v0): good Next.js screens; no system behind them. - Base44 (https://www.solvewithsoftware.com/rescue/base44): hosted and closed; the data and the screens come out, the back end has to be rebuilt. - Bubble (https://www.solvewithsoftware.com/rescue/bubble): no code export at all; a rebuild with the workflows as the specification. - Power Apps (https://www.solvewithsoftware.com/rescue/power-apps): readable Power Fx source that only runs on Microsoft's platform; fix in place or rebuild, decided on evidence. - FlutterFlow (https://www.solvewithsoftware.com/rescue/flutterflow): real Flutter code, exportable on the Pro plan; finish it in Flutter. - Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator): the structure and Deluge scripts export, the data comes out as CSV; fix in place or rebuild. - Zapier and Make (https://www.solvewithsoftware.com/rescue/zapier-make): the automations became the system; build a system for the process, keep them for the edges. - Cursor, Claude Code and Codex (https://www.solvewithsoftware.com/rescue/cursor-claude-code-codex): the code is already yours and in a mainstream stack; what's missing is the engineering around it. ## Your data Whatever went into the stalled app comes out. It never meets a change until the change has proven itself somewhere else: built and tested against a copy in a test environment, then run in staging with the data migrated, checked and reconciled there. Only when the tests have shown it's safe does anything connect to live. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an AI-built app the assessment is mostly reading code and testing the parts a demo never exercises, and the report says what's sound, what isn't, and what finishing costs as a fixed price. Everything after that is priced by the report. Payment terms are on the pricing page (https://www.solvewithsoftware.com/pricing). ## What it runs on afterwards Everything we build or finish runs on open, widely used technology: React, Node and TypeScript, .NET, PostgreSQL or SQL Server, mainstream cloud. It lives in your own accounts from day one, with full source code and ownership transferring to you on final payment. Any competent developer can pick it up, including the next AI tool, because there's a real codebase for it to work on. We use AI-assisted development ourselves, from first design to final release, and our own platforms run the Claude API in production. The difference is the foundations underneath it. ## How we approach it Read the code before promising anything. Marc Allington leads the assessment and the work that follows. He builds with AI tooling daily and has taken over enough hand-written systems to tell quickly what a generated codebase has and hasn't got. Then the same method as any other takeover: understand, stabilise, finish one process at a time, with working software at the end of each stage. ## What we check first in a stalled build The first pass of the assessment on an AI-built app, in the order we do it: 1. **Can the code be exported?** Into a repository you control, with a build that runs outside the tool. If not, that shapes every option. 2. **Who can do what?** Every screen and API call tested as a logged-out user, as the wrong user, and as a user typing something unexpected. 3. **What happens when it fails?** A payment that times out, a record saved twice, two people editing at once. 4. **Does the data hold together?** Duplicates, orphaned records, fields that mean two things. 5. **What was never finished?** Stubs, hard-coded values, features that exist as a button and nothing else. 6. **Can it be backed up and restored?** Tried, not assumed. The report scores each, states what it means for finishing versus rebuilding, and prices both. ## Questions Q: Was the money we spent on the tool wasted? A: Rarely. The screens, the flow and the rules you discovered along the way are the specification a project would otherwise spend weeks producing. Even in a rebuild, they carry across. Q: Can we keep using Lovable or Replit alongside you? A: Once the code is in your own repository with proper foundations under it, yes. AI tools work well on a real codebase with tests and structure. The problems come when the tool is the only place the app exists. Q: Our app is in Bubble. Is that different? A: Yes. Bubble holds the logic and the data on its platform, so there's no code to export in the usual sense. The choice is between finishing it there, with the platform's limits, or rebuilding on open technology with the data moved across. The assessment sets out both with a price. Q: How do we know if it's secure enough to use? A: Assume it isn't until it has been tested, because security is the part these builds most often skip. It's the second thing we check, and the report says plainly what we found. Q: It's about 70% done. How much is left? A: Usually more than 30%, because the missing part is the foundations rather than the features. The assessment gives you a fixed price for finishing, so you're deciding on a number rather than a percentage. --- # Our system is too risky to change URL: https://www.solvewithsoftware.com/problems/too-risky-to-change Title: Business System Too Risky to Change? Description: Every change breaks something? The answer is stages, not a leap: modernised alongside the live system, tested in staging first. From £395 + VAT. Last reviewed: 2026-09-04 A business system that's too risky to change is usually one where nobody can predict what a change will touch. Solve With Software takes that risk out in stages: understand the system first, put a safety net under it, then change one process at a time in a staging environment that mirrors live, with the old system kept as a fallback. Nothing connects to live data until the tests have shown it's safe. ## What 'too risky' looks like from inside The last change broke something that had nothing to do with it. There's no test system, so every change is tried on live, usually on a Friday evening with everyone watching. One person is able to change it, and they'd rather not. The business has stopped asking for improvements because it knows the answer. And at least one supplier has said the only safe option is to rewrite the lot. If two of those are true, the system isn't the problem. The lack of a safety net is. ## Why changes break things Not because the system is old. Because nobody can see what depends on what. A report reads a column that a screen repurposed in 2016. A scheduled job assumes a file will be in a folder that a change moved. Two processes share a table and only one of them was mentioned when the change was specified. None of that is unusual, and none of it is visible without a map (https://www.solvewithsoftware.com/problems/no-documentation). Add no tests and no staging environment, and every change is a guess tested on the business. The fix is not a rewrite. (https://www.solvewithsoftware.com/problems/replace-or-modernise) A rewrite has all the same hidden dependencies, plus new ones. The fix is to make the dependencies visible and to give changes somewhere safe to fail. ## How staged modernisation works 1. **Map it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) writes down what the system does, what depends on it and what it depends on. That map is what makes the next steps safe. 2. **Put a safety net under it.** Source code into version control. A backup that has been restored and proven to work, rather than one that was only ever taken. A test environment that's a copy of live. Tests around the processes that matter most. 3. **Change one process at a time.** The new or repaired piece runs in staging alongside the live system, sharing the same data, until the tests and the people who use it say it's right. Then it goes live, and the old route stays open as a fallback. 4. **Repeat, or stop.** Each stage is priced before you commit to it. Each ends with working software you've already paid for. Stop after any stage and keep everything. No big bang. No Friday-night switchover. No leap of faith. ## Do we need to replace everything? **Usually not. A system that's too risky to change is often sound underneath and simply unmapped.** Once it's mapped and under test, most of what people wanted for years turns out to be a series of small, safe changes. If your system is fundamentally sound, we'll take it over, stabilise it and build what's missing. If it isn't, the assessment says so and prices a staged replacement instead. ## Your data It never meets a change until the change has proven itself somewhere else. We build and test against a copy in a test environment, then run the new piece in staging alongside the live system, migrating, checking and reconciling the data there first. Only when the tests have shown it's safe does anything connect to live, and the old system stays available as a fallback until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. Each stage after that has its own fixed price, so an overrun is our risk rather than yours. Payment terms are on the pricing page (https://www.solvewithsoftware.com/pricing): 40% on signature, 40% at the first working version, 20% on handover, per stage. ## How long it takes Each stage takes one process and gets it live. Something working within six weeks is the usual first milestone, and it's soon enough to find out whether we've understood how you work before you commit to anything bigger. ## The risk of not changing A system that can't be changed can't be patched either. Windows Server 2016 support ends in January 2027. SQL Server 2016 security updates ended in July 2026 for most licence holders. The analogue phone lines some systems still dial or alert over go in January 2027. "Too risky to change" holds right up until a date in the calendar makes not changing the riskier option. ## How we approach it One accountable lead, a safety net before any change, and open technology afterwards. The person you speak to on the consultation leads every stage. Anything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment. ## What a first stage looks like This is the method rather than a client story; case studies follow as clients agree to them. For a system where one process matters most: **Before anything changes.** The source code goes into version control. A backup is taken, restored somewhere else, and proven to work. A test environment is built as a copy of live. Tests are written around the process about to change, so there's a way to know it still works. **The one process.** Usually the one that hurts most or carries the most risk. It's repaired or rebuilt, then run in staging alongside the live system on the same data. The people who use it check it. The data is reconciled. Then it's switched, with the old route left open. **At the end of the stage.** That process working. A short report on what the stage found, including anything the map missed. A fixed price for the next stage, if you want one. Every stage after the first follows the same shape, which is why each one can be priced before you commit to it. ## Questions Q: Can you change it without taking it offline? A: Yes. The new piece runs in staging alongside live until it's right, then switches over at a quiet moment, and the old route stays open. Your team keeps working throughout. Q: What if a change does break something? A: Roll back. The old system is kept as a fallback and the backup has been proven to restore before anything changes. That's the point of building the safety net first. Q: Our developer says it has to be rewritten from scratch. Are they wrong? A: Sometimes a rewrite is right, and the assessment will say so if it is. But 'too fragile to touch' more often means 'nobody has mapped it', and mapping it costs a fraction of rewriting it. Q: Can we stop after one stage? A: Yes. Each stage ends with working software you've already paid for, with the source code and ownership transferring to you. There's no charge for stopping and no licence to keep paying. Q: Do you test on our live system? A: No. We test on a copy in a test environment, then in staging alongside live. Live is the last place a change arrives, not the first. --- # Taking over a stalled Base44 app URL: https://www.solvewithsoftware.com/rescue/base44 Title: Finish a Stalled Base44 App Description: Base44 keeps the back end and data on its own platform. What exports, what doesn't, and how we move an app onto hosting you own. From £395 + VAT. Last reviewed: 2026-09-04 A Base44 app is harder to take over than a Lovable or Replit one, because Base44 is a hosted platform rather than a code generator: as of September 2026 the front end can be synced to GitHub on paid plans, but the back end runs through Base44's own servers and the data sits in Base44's database, with no self-hosting. Solve With Software treats it as a migration: extract the data and the screens, rebuild the back end on technology you own, and run the two side by side until the new one has proven itself, on a fixed price from the assessment. ## What Base44 is, and why that matters Base44 is a prompt-first app builder that hosts what it builds. You describe the app, it generates the screens, a database, login and the logic, and it runs the result on its own infrastructure. That's why it's so quick to get something working, and it's why the question when it stalls is different from the other tools. Base44 was acquired by Wix in 2025. That's not a reason to leave, but it's a reason to know exactly what you own. As of September 2026: the front-end code can be synced to a GitHub repository on paid plans, and that feature was still in beta on most plans this year. The back end isn't yours to export; the front end calls Base44's servers through Base44's SDK. Your data lives in Base44's managed database. There's no way to run the app anywhere but Base44. ## What you can take out - **The screens**, as React code, if you're on a plan with GitHub sync. They're a specification for the rebuild even where the code itself isn't reused, because they call a back end that won't exist outside Base44. - **The data**, through Base44's export and API. Every entity, every record, every file, pulled out and checked against what the app shows. - **The logic, as a description.** The rules the app enforces are visible in how it behaves and in the prompts that built it. They can be written down. They can't be exported as code that runs elsewhere. - **The users**, as records. Passwords don't travel; a rebuild means a reset or a fresh login. ## What has to be rebuilt The back end, in full. Every server-side operation the app performs runs on Base44, so leaving means building it: the database, the rules, the authentication, the file storage, the integrations, and the hosting. The screens can often be adapted rather than rewritten, with their calls to the Base44 SDK replaced by calls to the new back end. That's more work than finishing a Lovable app and less than starting from nothing, because the screens and the data give the rebuild its specification. ## Stay on Base44 or leave? **Stay if the app is internal, the stakes are modest, and the platform's limits aren't what stalled it.** In that case the fix might be finishing it inside Base44 with better prompts and a clearer specification, and we can help with that. **Leave if the business depends on it, if you need to own the data and the code, if the platform can't do something you need, or if a platform decision you don't control would hurt you.** The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, with one difference: for Base44, "replace" is more often the answer, because so little of the running system can come with you. The assessment sets both options out with a fixed price on each. ## How we take a Base44 app over 1. **Write down what it does.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps every screen, every entity, every rule the app enforces and every outside service it touches. For a Base44 app this is done from the running app, the exported front end where available, and the data. 2. **Get the data out and check it.** Every record and file, reconciled against what the app shows. 3. **Design the new back end** from the map: a database you own, the rules, login, storage, integrations, hosting in your accounts. 4. **Adapt or rebuild the screens**, replacing their Base44 calls with calls to the new back end. 5. **Run both side by side.** The new system in staging with the migrated data, checked by the people who use it, reconciled, then switched, with Base44 kept available until you're confident. 6. **Finish the features** that never got finished, one at a time, each priced before you commit. ## Your data Extracted once, checked, and never touched by a change until the change has proven itself somewhere else. The migration is tested against a copy in a test environment, then run in staging with every record and file reconciled against Base44. Only when the tests have shown it's safe does anything connect to live, and the Base44 app stays running as a fallback until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Base44 app it maps the running system, extracts a sample of the data to see how it comes out, and prices both staying and leaving as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Know what you own before deciding anything. Marc Allington builds with AI tooling daily and has taken over enough systems to know that the data and the rules are the valuable part, whichever platform they're on. Everything we build runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment. ## What we check first in a Base44 build In order, on the first pass of the assessment: 1. **Which plan, and is GitHub sync available?** Decides whether the screens come out as code or as a description. 2. **Every entity and every record.** Pulled through export and API, counted, and compared with what the app shows. 3. **Every rule the app enforces.** Written down from behaviour, from the prompts that built it, and from the people who use it. 4. **Every outside service.** Email, payments, files, other systems, and how each is connected. 5. **Users and permissions.** Who exists, who can do what, and what a rebuild means for their logins. 6. **What the platform can't do** that the business needs. Often the reason it stalled. The report sets out staying and leaving side by side, with a fixed price on each. ## Questions Q: Can we export our Base44 app? A: Partly, as of September 2026. The front-end code can sync to GitHub on paid plans, and the data can be exported. The back end can't; it runs on Base44's servers. So leaving means rebuilding the back end, with the screens and the data as the specification. Q: Base44 is owned by Wix now. Should we be worried? A: Not worried, but clear-eyed. A hosted platform can change its pricing, its features or its terms, and you'd have no say. If the business depends on the app, owning it is the safer position. If it's an internal tool, staying may be fine. Q: Is our data safe to get out? A: Yes. It comes out through Base44's export and API, and we reconcile every entity and record against what the app shows before anything relies on it. Q: Could you just finish it inside Base44? A: Sometimes, and we'll say so if that's the right answer. It depends on whether what stalled it is the platform's limits or the lack of a clear specification. The assessment tells you which. Q: How long does leaving Base44 take? A: It depends on how many entities and rules the app has, which the assessment counts. The shape is the usual one: the new system running on your data in staging within about six weeks, then one process at a time until Base44 can be switched off. --- # Finishing a stalled Bolt app URL: https://www.solvewithsoftware.com/rescue/bolt Title: Finish a Stalled Bolt App Description: Bolt.new builds a React front end fast. Back end, hosting and security are usually missing. We build the system behind the screens. From £395 + VAT. Last reviewed: 2026-09-04 A Bolt app is usually a good front end without a system behind it. Bolt.new writes real React and exports the whole project to GitHub, so the screens are yours. What tends to be thin is the back end: the database rules, the server-side logic, the integrations and the hosting, because Bolt ran the app inside your browser and never on a server. Solve With Software takes the code into your repository, builds the back end the screens assume, and finishes it one feature at a time, on a fixed price from the assessment. ## What Bolt gives you A front end, fast, and a clean way out. Bolt.new builds React applications and runs them in the browser as you work, using StackBlitz's in-browser environment rather than a server. When you export, you get a standard project: open it, install the packages, run it, and it works on your machine the way it did in Bolt. Push to GitHub is built in. For the back end, Bolt offers its own database or a connection to a Supabase project, which gives you a real database, login and server functions. Whether your app has any of that depends on how far the prompts got. ## What Bolt doesn't give you A server. Bolt's whole approach is to run the project in the browser, which is why it feels so fast and why the export is so clean. It also means the app has never run in production. There's no hosting, no domain, no environment variables set anywhere but the tool, no scheduled jobs, no logs. The other gap is the back end itself. A Bolt app often has beautifully finished screens for features whose server side is a placeholder: the form that "submits", the payment that "processes", the report that shows sample data. The front end is the specification for a back end that still has to be built. ## What's usually missing - **The back end.** Server functions that exist as stubs, or as calls to a database that has no rules. - **Database security rules.** If Supabase is connected, the same finding as with any browser-facing database: without row-level security on every table, users can read each other's data. - **Environment variables and secrets.** Keys in the front-end code, because that's where Bolt could reach them. - **Hosting and deployment.** Nothing exists outside the tool. - **Integrations.** The link to Stripe, Xero or the warehouse system was on the list and got as far as a button. - **Tests and staging.** The app was tested by looking at it. ## Finish it or rebuild? **Finish the front end, build the back end.** The screens are usually worth keeping as they are, and the export makes that straightforward. The back end is often built rather than fixed, because there's little to fix, and it's designed from the screens, which is a good order to do things in. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the code. ## How we take a Bolt app over 1. **Export to GitHub**, into a repository in your organisation, and confirm it builds on a clean machine. 2. **Read it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment): which screens are wired to something real, which are wired to nothing, what the database looks like if there is one, and what the app expects to exist. 3. **Give it a back end.** A database you own with rules on every table. Server functions for the things the screens assume. Secrets out of the front end and into a store you control. 4. **Give it a home.** Hosting in your accounts, a domain, environment variables set properly, logs. 5. **Foundations.** Test and staging environments, integrity constraints, error handling, a backup that's been restored. 6. **Finish the features**, one at a time, each priced before you commit. ## Your data Often there isn't much yet, which makes a Bolt takeover simpler than most. Where there is, it never meets a change until the change has proven itself somewhere else: tested on a copy in a test environment, then run in staging with the data reconciled, before anything connects to live. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Bolt app it establishes which screens have a real back end and which don't, then prices building the rest as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Keep the screens, build the system behind them. Marc Allington builds with AI tooling daily and has taken over enough hand-written systems to tell quickly what a generated codebase has and hasn't got. Everything we build runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment. ## What we check first in a Bolt build In order, on the first pass of the assessment: 1. **Does the export build and run on a clean machine?** It usually does; this is the easy one. 2. **Which screens talk to something real?** Each button and form traced to a server function, a database call, or nothing. 3. **Is there a database, and whose is it?** Bolt's, Supabase, or none. Rules on every table if there is one. 4. **Where the secrets are.** Anything in the client bundle that shouldn't be. 5. **What the app assumes exists.** Payment provider, email, file storage, external APIs, and whether any of them is connected. 6. **Where it would run.** Hosting, domain, environment, logs. 7. **Backup and restore**, if there's data yet. Tried, not assumed. The report scores each, says what it means for finishing, and prices it. ## Questions Q: It works when we run it locally. Why isn't it live? A: Because running on a laptop and running for customers are different jobs. It needs hosting, a database with rules, secrets kept off the front end, and a way to know when it breaks. That's the takeover. Q: We connected Supabase in Bolt. Is the back end done? A: Partly. Supabase gives you a database, login and server functions. Whether the tables have security rules, whether the functions do what the screens assume, and whether the secrets are where they should be is what the assessment checks. Q: Can our team keep using Bolt for the front end? A: Yes, once the code is in your repository. Bolt can open a GitHub project, so the screens can keep being prompted while the back end is built and reviewed properly. Q: Would it be quicker to start again? A: Rarely. The screens are usually worth keeping and they're the specification for the back end. Starting again throws away the part that's done to redo the part that isn't. Q: How long to get it live? A: It depends on how much of the back end exists, which the assessment measures. The shape is the usual one: something working in your own hosting within about six weeks, then features one at a time, each priced before you commit. --- # Moving off Bubble URL: https://www.solvewithsoftware.com/rescue/bubble Title: Bubble App Migration and Rebuild Description: Bubble apps can't be exported as code. The data, design and workflows come out as a spec. Off Bubble without a cutover weekend. From £395 + VAT. Last reviewed: 2026-09-04 A Bubble app can't leave Bubble as code: there is no source export, and there never has been. What can leave is the data, by export and API, and the design, as a description of every page and workflow. Solve With Software treats leaving Bubble as a rebuild with an unusually good specification: the workflows say exactly what the system does. The new system is built on technology you own, run alongside Bubble with the data migrated and reconciled, and switched one process at a time, on a fixed price from the assessment. ## Why businesses leave Bubble Usually one of four things. The app has outgrown the platform's performance or its pricing. The business needs something Bubble can't do, or can only do through a plugin nobody maintains. The developer who built it, often a freelancer, has moved on and nobody else will touch a Bubble editor. Or the board has asked who owns the system and didn't like the answer. None of those is a criticism of Bubble. It got the business a working system without a development team, which is its job. The question is what happens next. ## What you can take with you - **The data.** Every data type exports as CSV, and the Bubble API can pull records with their relationships intact. Files in Bubble's storage come out too. This is the valuable part, and it comes out cleanly. - **The design, as a description.** Bubble can export a file describing the whole app: pages, workflows, data types, styles. It isn't code and it doesn't run anywhere else, but it's a complete map of what the app does. - **The workflows, as the specification.** Every Bubble workflow is a business rule written out step by step: when this happens, do these things. That's precisely what a rebuild needs and precisely what most legacy systems don't have. - **The users**, as records. Passwords don't travel; the new system starts with a reset or a fresh login. ## What has to be rebuilt Everything that runs. The pages, the workflows, the login, the file handling, the plugins' behaviour, the integrations. There's no shortcut, and anyone promising a one-click conversion is promising something Bubble doesn't allow. What makes it tractable is the specification. A rebuild from a Bubble app knows what every page shows, what every button does and what every rule is, before a line is written. Most rebuilds spend their first weeks discovering that. This one starts with it. ## The staged path 1. **Map it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) reads the pages, workflows and data types, and writes them down as a system description with the rules made explicit. 2. **Get the data out and check it.** Every data type, every record, every file, reconciled against Bubble. 3. **Design the new system** from the map, on a mainstream web stack in your own accounts. 4. **Build one process at a time**, starting with the one that matters most, and run it in staging on the migrated data, checked by the people who use it. 5. **Switch that process**, with Bubble still running everything else, and the data kept in step until the next process moves. 6. **Repeat until Bubble can be switched off.** Each stage priced before you commit; stop after any stage with a working system. No cutover weekend. Bubble keeps running until the last process has proven itself elsewhere. ## Your data It leaves Bubble once, checked, and never meets a change until the change has proven itself somewhere else. The migration is tested against a copy in a test environment, then run in staging with every data type and record reconciled against Bubble. Only when the tests have shown it's safe does anything connect to live, and Bubble stays running as a fallback until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Bubble app it maps the pages, workflows and data types, extracts a sample of the data to see how it comes out, and prices the rebuild process by process as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Treat the workflows as the specification and the data as the asset. Marc Allington has rebuilt systems from worse maps than a Bubble app gives you. Everything we build runs on open, widely used technology in your own accounts, with full source code and ownership transferring to you on final payment, so the next time the board asks who owns the system, the answer is you. ## What we check first in a Bubble app In order, on the first pass of the assessment: 1. **Every data type, field and relationship**, and how many records each holds. 2. **Every page and every workflow**, read as rules: triggers, conditions, actions. 3. **Plugins.** What each one does and whether it's still maintained; each is a dependency the rebuild has to replace. 4. **Integrations and API connections.** Every outside service the workflows call. 5. **Users, roles and privacy rules.** Who can see what, as Bubble enforces it today. 6. **A sample export.** A data type pulled out through CSV and the API, to see how it comes out and what needs cleaning. 7. **What the business needs that Bubble can't do.** Often the reason for leaving, and a requirement for the new system. The report turns that into a specification and a fixed price for the first process. ## Questions Q: Can't a tool convert our Bubble app to code? A: No. Bubble doesn't export source code, so there's nothing for a tool to convert. Services that offer it are rebuilding, and so are we; the difference is that we say so and price it process by process. Q: Does Bubble have to stay running during the rebuild? A: Yes, and that's the point. Each process moves when its replacement has proven itself in staging on your data, and Bubble keeps running everything that hasn't moved. There's no day when everything switches at once. Q: Our data types are linked to each other. Does that export? A: Yes. CSV export flattens the links, but the API returns records with their relationships, and we use both. Every relationship is reconciled in staging before anything relies on it. Q: Should we leave Bubble at all? A: Not necessarily. If the app does its job, the cost is acceptable and someone can maintain it, staying is a real option and the assessment will say so. Leave when the platform, the cost or the ownership has become the problem. Q: How long does moving off Bubble take? A: It depends on how many pages, workflows and data types there are, which the assessment counts. The shape is the usual one: the first process running on your data within about six weeks, then one at a time until Bubble can be switched off. --- # Finishing an app built with Cursor, Claude Code or Codex URL: https://www.solvewithsoftware.com/rescue/cursor-claude-code-codex Title: Finish a Cursor, Claude Code or Codex App Description: Built an app with Cursor, Claude Code or Codex and it stalled? The code is yours. We add the engineering around it and finish it. From £395 + VAT. Last reviewed: 2026-09-04 An app built with Cursor, Claude Code or Codex is the easiest of the AI-built apps to take over, because the code is ordinary, in a mainstream stack, and already in a repository you own. There's nothing to export. What's usually missing is the engineering around the code: a designed data model, tests, authorisation, separate environments, and a structure that accepts the next feature instead of fighting it. Solve With Software reads the code, puts those foundations under it, and finishes it one feature at a time, on a fixed price from the assessment. ## How it happens You had a clear idea, the tools were good, and in a few weekends there was an app. Screens, a database, login, the first real users. Each feature came quicker than the last, until one didn't. A change in one place broke three others. The assistant started patching its own patches. Fixed bugs came back. And the feature the business needs next, the one that touches everything, won't come. None of that is a failure of the tools. The assistant wrote what was asked, one request at a time, and nobody was holding the whole design. That's the job that was missing. ## What you have More than most rescue cases. The code is in a language and framework a developer can read: usually TypeScript with Next.js or React, or Python, with Postgres or Supabase behind it. It's in a Git repository, or can be in one this afternoon. It runs on your machine and probably on a host you chose. There's no platform holding the back end, no export to negotiate, no per-user licence. That's the difference from a Lovable (https://www.solvewithsoftware.com/rescue/lovable), Bolt (https://www.solvewithsoftware.com/rescue/bolt) or Bubble (https://www.solvewithsoftware.com/rescue/bubble) app. The question isn't how to get the code out. It's what the code is missing. ## What's usually missing - **A designed data model.** Tables were added as features needed them. Now the same fact lives in two places and they disagree. - **Tests.** The app was tested by using it. Every change is a chance to break something that worked last week, which is why the last features won't come. - **Authorisation.** Login exists. The check that one customer can't see another's data often doesn't, on every route. - **Environments.** One database, and it's live. Changes are tried on real data. - **Secrets.** API keys in the repository, or in a file on one laptop. - **Structure.** Files that grew to thousands of lines, logic in the screens, the same thing done four ways. The assistant only ever saw the part it was asked about. - **Operations.** Error reporting, logging, a backup that's been restored, a deployment that doesn't depend on your machine. ## Finish it or rebuild? **Finish, nearly always. The stack is mainstream, the screens are what your users already know, and the data model is close.** The work is foundations first (tests around what works, environments, authorisation, secrets, a data model straightened out), then the structure that's blocking progress reworked where it needs to be, then the features in order of value. Rebuild when the structure has stopped accepting changes at all, and even then the existing app is the specification and the data carries across. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the code. ## How we take it over 1. **Repository access**, and a build on a clean machine. This is where the missing secrets and the laptop-only steps show up. 2. **Read it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment): every route, every table, every place a rule is enforced or isn't, every outside service, and the structure that's blocking the next feature. 3. **Foundations.** Tests around the processes that work today, so they keep working. A test environment and a staging environment. Authorisation on every route. Secrets in a store you control. A backup that's been restored. 4. **Straighten what blocks.** The data model, and the parts of the structure that every new feature trips over. Not a rewrite; the minimum that makes the next feature possible. 5. **Finish the features**, one at a time, each priced before you commit. We use the same tools you did, with tests, review and a design held by a person. That's the part that was missing, not the tools. ## Your data It's already in a database you own, which is the good news. It never meets a change until the change has proven itself somewhere else: tested on a copy in a test environment, then run in staging with the data reconciled, before anything connects to live. Where the data model changes, the migration is rehearsed the same way. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an assistant-built app it reads the code, lists what's missing and what's blocking, and prices the foundations and each remaining feature as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Read it, make it safe, unblock it, finish it. Marc Allington builds with AI coding tools daily, Claude Code among them, with the tests and review around them that keep a codebase moving, so he can tell quickly what an assistant-built app has and hasn't got. Everything we finish runs on open technology in your own accounts, with full source code and ownership staying with you throughout. ## What we check first in an assistant-built app In order, on the first pass of the assessment: 1. **Does it build and run on a clean machine?** Secrets, environment variables, steps that only exist on your laptop. 2. **Who can do what?** Every route tested as a logged-out user and as the wrong user. 3. **The data model.** Every table, what duplicates what, and what the next feature needs that isn't there. 4. **Tests.** What exists, what runs, and what the app does that nothing checks. 5. **Structure.** The files and functions every recent change touched. That's where the next feature is stuck. 6. **Dependencies.** What's pinned, what's abandoned, what has a known vulnerability. 7. **Operations.** Hosting, backups, error reporting, and whether any of it has been tried. The report scores each, says what's blocking the next feature, and prices unblocking it. ## Questions Q: Can we keep building with Cursor or Claude Code ourselves? A: Yes, and you should. With tests, environments and a reviewed structure in place, the tools work far better than they did on the bare codebase. We'll set it up so your changes run through the same checks ours do. Q: Is AI-written code worse than hand-written code? A: It's as good as the design and the review it got. Assistant-built apps go wrong in predictable places: data models that grew rather than being designed, missing authorisation, no tests. Those are fixable, and the code around them is usually fine. Q: Why did it stall at the last feature? A: Because the last feature is the one that touches everything, and the structure was built one request at a time without anyone holding the whole design. Unblocking it is usually a data model fix and some restructuring, not a rewrite. Q: Will you rewrite it in your own stack? A: No. It's already in a mainstream stack, which is the main reason it's finishable. We work in the language and framework it's in. Q: How long to get it unblocked and finished? A: It depends on what's blocking and how many features remain, which the assessment measures. The shape is the usual one: foundations in place and the first blocked feature shipped within about six weeks, then one at a time, each priced before you commit. --- # Finishing a stalled FlutterFlow app URL: https://www.solvewithsoftware.com/rescue/flutterflow Title: Finish a Stalled FlutterFlow App Description: FlutterFlow exports a real Flutter project, so the app is finishable. Usually missing: backend rules, custom logic, store accounts. From £395 + VAT. Last reviewed: 2026-09-04 A FlutterFlow app is one of the better rescue candidates, because FlutterFlow generates an ordinary Flutter project and, on its Pro plan, exports it to GitHub or as a download. What stalls it is the part the visual builder can't express: custom logic, state that got complicated, backend security rules in Firebase or Supabase, and getting it through the app stores. Solve With Software takes the export into your own repository, puts the foundations under it and finishes it in Flutter, one feature at a time, on a fixed price from the assessment. ## What FlutterFlow gives you Real code. FlutterFlow builds the app visually and generates a Flutter project in Dart behind it, which is the same technology we build mobile apps in ourselves. On the Pro plan you can download the whole project or have FlutterFlow push it to a GitHub repository, and what comes out compiles and runs like any other Flutter app. That's the difference from a hosted builder. A FlutterFlow app can leave FlutterFlow and be finished by hand. It can also, with care, keep being edited in FlutterFlow: the tool pushes to a branch it owns and overwrites it each time, so hand-written changes have to live in a separate branch and be merged, which is a workable arrangement if it's planned. ## What usually stalls it - **Logic the builder can't express.** FlutterFlow has custom code slots for actions, functions and widgets, and the app stalls at the point where the business rule was too involved for the visual tools and the custom code was never written well. - **State.** Small apps keep their state in the builder's app-state; as the app grows, that becomes tangled, and screens start disagreeing about what's true. - **Backend rules.** Firebase security rules or Supabase row-level security left at their permissive defaults, so any user can read any data. The most common serious finding. - **Performance.** Lists that load everything, images that aren't sized, queries on every rebuild. - **The stores.** Signing keys, developer accounts, screenshots, privacy declarations, review rejections. The last mile that builders don't do. - **Tests, staging, monitoring.** The app was tested by using it. ## Finish it or rebuild? **Finish, nearly always. The export is Flutter, the screens are what the team has already used, and the data model in Firebase or Supabase is usually close.** The work is foundations (security rules, state, tests, a test build and a staging backend, the store accounts in your name), then the custom logic done properly, then the unfinished features in order of value. Rebuild only when the generated structure fights every change, and even then the screens carry across as the design. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the export. ## How we take a FlutterFlow app over 1. **Export the project** into a repository in your organisation, and confirm it builds on a clean machine for both platforms. 2. **Read it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment): every screen, every custom action, the app state, the backend rules, the store status, and what the app talks to. 3. **Decide about FlutterFlow.** Keep editing there with a branching arrangement, or move to hand-maintained Flutter. Depends on how much custom code the app needs from here. 4. **Foundations.** Security rules on the backend. State straightened out. A test build, a staging backend, error reporting. Store accounts and signing keys in your name. 5. **Finish the features**, one at a time, each priced before you commit, and ship each through the stores. ## Your data It stays in Firebase or Supabase, in a project you own, and it never meets a change until the change has proven itself somewhere else: built and tested against a staging backend with a copy of the data, then released to a test group, before it reaches the store. The backend rules are tightened before any new users arrive, not after. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a FlutterFlow app it reads the export, the backend rules and the store status, and prices finishing as a fixed number. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Read the export before promising anything, then finish it in the language it's already in. Marc Allington builds mobile apps in Flutter, so a FlutterFlow export is familiar ground. Everything we finish runs in your own accounts, with full source code and ownership transferring to you on final payment. ## What we check first in a FlutterFlow build In order, on the first pass of the assessment: 1. **Does the export build, for iOS and Android, on a clean machine?** 2. **Backend rules.** Firebase security rules or Supabase policies, tested as a logged-out user and as the wrong user. 3. **Custom code.** Every custom action, function and widget, read for what it does and what it assumes. 4. **App state.** What's held where, and which screens depend on it. 5. **Store status.** Which accounts exist, whose name they're in, where the signing keys are, and what the last submission said. 6. **Performance.** The screens that load everything, the images that aren't sized. 7. **Integrations.** Payments, notifications, maps, anything with a key. The report scores each, says what it means for finishing, and prices it. ## Questions Q: Can we keep using FlutterFlow after you've taken it over? A: Yes, with a branching arrangement: FlutterFlow pushes to its own branch and overwrites it, so hand-written changes live in another branch and are merged. It works if it's planned. If the app needs a lot of custom code from here, moving to hand-maintained Flutter is simpler. Q: We're not on the Pro plan. Can we still get the code? A: Export is a Pro-plan feature, so the first step is a month of Pro to get the project out. After that the code is yours and the plan can lapse. Q: Is our Firebase data secure? A: Assume not until the rules have been tested. Builders leave security rules permissive so the app works during development, and they often stay that way. It's the second thing we check. Q: It was never submitted to the app stores. Can you do that? A: Yes. Developer accounts in your name, signing keys kept properly, the privacy and review requirements met, and a first release through a test group before the public listing. It's part of the finish. Q: How long to get it finished and in the stores? A: It depends on how much custom logic the app needs, which the assessment measures. The shape is the usual one: a test build in your hands within about six weeks, then features one at a time, each priced before you commit. --- # Finishing a stalled Lovable app URL: https://www.solvewithsoftware.com/rescue/lovable Title: Finish a Stalled Lovable App Description: Your Lovable app looks finished and isn't. What Lovable gives you, what Lovable Cloud keeps, and how we take one over. From £395 + VAT. Last reviewed: 2026-09-04 A Lovable app is a good rescue candidate, because Lovable produces ordinary React and Supabase code and syncs it to GitHub, so the code is yours. What tends to be missing is everything a demo doesn't exercise: database security rules, data integrity, error handling, tests and a deployment you control. Solve With Software takes the code into your own repository, moves the backend out of Lovable Cloud where that's right, puts the foundations under it and finishes it one feature at a time, on a fixed price from the assessment. ## What Lovable gives you More than most builders. Lovable writes a React front end with Tailwind, and a Supabase backend for the database, login, file storage and server functions. It syncs the whole project to a GitHub repository, two ways: edits in Lovable land in the repository, and changes pushed to the repository flow back into Lovable. That matters, because it means the app can leave the tool without leaving the tool behind. Since July 2026 Lovable has also had explicit Export, Pause and Remove controls in the project settings, so getting the code out is a supported route rather than a workaround. So if your Lovable app has stalled, you're not starting again. You're finishing. ## What Lovable keeps The backend, by default. Many Lovable apps run on Lovable Cloud, which bundles the database, authentication, storage and functions behind one managed backend. The code is yours, but the data and the users live there, and as of September 2026 there's no one-click move from Lovable Cloud to a Supabase project you own. The official export route resets every user's password. Third-party tools move the tables, users and files without that, and we've read them closely enough to know where they break. Whether to move off Lovable Cloud is a decision, not a reflex. For an internal tool with six users, staying may be fine. For a customer-facing app with real accounts, owning the database is the first job. ## What's usually missing The same list as any AI-built app, with Lovable's particular shape: - **Supabase security rules.** The database is reachable from the browser by design. Without row-level security on every table, any logged-in user can read every other user's data, and sometimes a logged-out one can too. This is the most common and most serious finding. - **Secrets in the front end.** Keys that should be server-side, sitting in the client bundle. - **Server functions half-built.** The edge functions that were going to send the email, take the payment or talk to Xero exist as a stub or a first attempt. - **No transactions, no constraints.** A failure halfway through leaves half a record; the same customer exists three times. - **No tests, no staging.** Every change was tried on the live app, because that's the only app there was. - **Deployment nobody controls.** Hosted by Lovable, with no backup anyone has tested. ## Finish it or rebuild? **Usually finish. The front end is real React, the data model is usually close, and the screens your team has already used are the specification.** The work is foundations first (security rules, integrity, tests, a deployment in your accounts), then the unfinished features in order of value. Rebuild only when the security holes run through the structure or the data model fights every change. Even then the Lovable screens carry across as the design, so it's a short rebuild. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the code. ## How we take a Lovable app over 1. **Connect GitHub**, if it isn't already, so the repository is in your organisation. From this point the code exists outside Lovable. 2. **Read the code and the database.** Every table's security rules, every function, every secret, every place the app talks to something outside itself. This is the assessment (https://www.solvewithsoftware.com/legacy-system-assessment). 3. **Decide about Lovable Cloud.** Stay, or move the database, users and storage to a Supabase project you own. If moving, the migration is tested on a copy and run in staging with every user and record reconciled before anything switches. 4. **Foundations.** Security rules on every table. Secrets out of the front end. Constraints and transactions where the data needs them. A test environment and a staging environment. A backup that's been restored. 5. **Finish the features**, one at a time, each priced before you commit. 6. **Keep using Lovable if you want to.** With the code in your repository and the foundations in place, Lovable's two-way sync means your team can keep prompting for small changes, and we review what comes back. ## Your data It never meets a change until the change has proven itself somewhere else. Any move out of Lovable Cloud is tested against a copy in a test environment, then run in staging alongside the live app with users, records and files reconciled. Only when the tests have shown it's safe does anything connect to live, and the Lovable-hosted version stays available as a fallback until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Lovable app it's mostly reading code and testing the parts a demo never exercises, and the report gives a fixed price for finishing. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Read the code before promising anything. Marc Allington builds with AI tooling daily, so he can tell quickly what a generated codebase has and hasn't got. Everything we finish runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment. ## What we check first in a Lovable build In order, on the first pass of the assessment: 1. **Is the repository in your GitHub organisation, and does it build outside Lovable?** 2. **Row-level security on every table.** Tested as a logged-out user, as the wrong user, and as a user editing the URL. 3. **Where the secrets are.** Anything in the client bundle that shouldn't be. 4. **Lovable Cloud or your own Supabase.** Who owns the database, the users and the files, and what it would take to move them. 5. **The functions.** Which server functions exist, which are stubs, and which talk to outside services. 6. **Integrity.** Constraints, transactions, duplicates. 7. **Backup and restore.** Tried, not assumed. The report scores each, says what it means for finishing versus rebuilding, and prices both. ## Questions Q: Can we keep using Lovable after you've taken it over? A: Yes. Lovable's GitHub sync is two-way, so once the code is in your repository with the foundations in place, your team can keep prompting for small changes and we review what comes back. That's a sensible arrangement for a lot of businesses. Q: Do we have to move off Lovable Cloud? A: Not always. For an internal tool with a handful of users, staying can be fine. For an app with customer accounts or data you'd be embarrassed to lose, owning the database is the first job. The assessment says which you are. Q: We heard moving the users resets everyone's password. Is that true? A: With the official export route, yes, as of September 2026. There are migration tools that move users without a reset, and we test the migration on a copy and in staging before it touches your real users. Q: Is our Lovable app secure? A: Assume it isn't until the database rules have been tested. Lovable apps talk to Supabase from the browser, so without row-level security on every table, users can read each other's data. It's the second thing we check. Q: It's nearly done. How much can there be left? A: Usually more than it looks, because what's missing is foundations rather than features. The assessment turns that into a fixed price, so you're deciding on a number rather than a guess. --- # Taking over a stalled Power Apps app URL: https://www.solvewithsoftware.com/rescue/power-apps Title: Stalled Power Apps App: Fix or Rebuild Description: Power Apps built in-house and stuck: slow, over the limits, builder gone. Fix in place, or rebuild on technology you own. From £395 + VAT. Last reviewed: 2026-09-04 A Power Apps app is readable but not portable: since Microsoft's Git integration, the source of a canvas app is plain YAML with Power Fx formulas you can read and version, but it only runs on the Power Platform. Solve With Software takes one over by reading that source and the data behind it, then deciding on evidence between fixing it in place, where the platform fits, and rebuilding it on technology you own, where the platform's limits or its per-user cost are what stalled it. Either way the data and the rules carry across, on a fixed price from the assessment. ## How a Power Apps app stalls Someone in the business built it, which is the point of Power Apps, and it worked. Then it grew. The list it reads went past the row limits, so the app silently shows the first two thousand records. A screen that was quick with ten users is slow with a hundred. The premium connector it needed moved everyone onto a licence the finance director didn't budget for. The person who built it left, and the formulas are theirs. None of that is a failure of Power Apps. It's a tool for building small, quick applications close to Microsoft 365, and the trouble starts when a small, quick application becomes the system. ## What you can take out - **The logic, readable.** A canvas app's source is stored as YAML with Power Fx formulas, and Microsoft's Git integration puts those files in a repository. That's a full description of every screen, control and rule. It runs nowhere but Power Apps, but it can be read, and it's the specification for whatever comes next. - **The data.** Dataverse tables, SharePoint lists (https://www.solvewithsoftware.com/modernise/sharepoint) or a SQL database, all exportable. Dataverse and SharePoint data moves to a database you own; SQL data usually stays where it is. - **The flows.** Power Automate flows are the app's background logic: approvals, emails, scheduled jobs. Exportable as definitions, readable as rules, rebuilt on the other side. - **The users and roles**, as records, from Microsoft 365. ## Fix it in place, or rebuild? **Fix it in place** when the app is small, close to Microsoft 365, and stalled by something the platform can solve: a query rewritten to delegate properly, a screen restructured, a flow that fails quietly made to fail loudly. Power Apps is good at what it's good at, and we'll say so. **Rebuild on technology you own** when the app has become the system. Row limits that can't be delegated around, performance that doesn't recover, a per-user licence bill that grows with the business, integrations the connectors can't reach, or the need to give customers access. The rebuild starts from the YAML and the flows as a specification, keeps the data, and runs alongside the Power Apps app until each process has proven itself. **Often both.** Stabilise it in place so it stops hurting, then move the processes that outgrew it. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the source and the data. ## How we take a Power Apps app over 1. **Get the source into Git**, using Microsoft's integration, so the app's definition exists somewhere you control and changes are visible. 2. **Read it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment): every screen, every formula, every data source, every flow, every connector, and the licence each one needs. 3. **Read the data.** What's in Dataverse, SharePoint or SQL, how clean it is, and how it comes out. 4. **Decide**, from evidence, per process: fix in place, or rebuild. 5. **Rebuild alongside**, where that's the answer. The new system runs in staging on the migrated data, checked by the people who use it, reconciled, then switched process by process. The Power Apps app stays until the last one has moved. 6. **Or fix in place**, priced as its own stage, with the same test-then-live discipline. ## Your data It comes out of Dataverse or SharePoint once, checked, and never meets a change until the change has proven itself somewhere else. The migration is tested against a copy in a test environment, then run in staging with every table and record reconciled, before anything connects to live. Where the data is already in SQL Server, it usually stays there and both systems share it. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Power Apps app it reads the source, the flows and the data, and prices fixing in place and rebuilding as fixed numbers, alongside what the current licensing costs a year. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Read the source before deciding anything, and be willing to say the platform is fine. Marc Allington has worked in Power Apps and in the web and .NET stacks apps move to when they outgrow it. Everything we build runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment, and no per-user licence. ## What we check first in a Power Apps build In order, on the first pass of the assessment: 1. **Is the source in Git?** If not, that's the first step, and it's Microsoft's own feature. 2. **Every data source**, and whether each query delegates. Non-delegable queries are where the row limits bite silently. 3. **Connectors and licences.** Which are premium, who needs them, and what that costs a year. 4. **Flows.** Every Power Automate flow, what triggers it, what it does, and whether it tells anyone when it fails. 5. **Performance.** Where the app is slow and why: screen load, data calls, formulas that recalculate on every keystroke. 6. **Who can do what.** Sharing, roles and what the data sources allow underneath the app. 7. **What the business needs that the platform can't do.** Often the reason it stalled. The report sets out fixing in place and rebuilding side by side, with a fixed price on each. ## Questions Q: Can we export our Power Apps app? A: The definition, yes: with Git integration the source is YAML with Power Fx formulas in a repository you control. It only runs on Power Apps, so a rebuild uses it as the specification rather than as code that moves. Q: Our app only shows some of the records. Why? A: Delegation. When a query can't be handed to the data source, Power Apps fetches a limited number of rows and works on those, silently. Some queries can be rewritten to delegate; some can't, and that's a sign the app has outgrown the platform. Q: The licence cost keeps going up. Is that fixable? A: Sometimes, by removing the premium connector that triggered it. Often not, because the app needs what the connector does. A rebuild on technology you own has no per-user licence, which is one of the numbers the assessment puts side by side. Q: Should we stay on Power Apps? A: If the app is small, close to Microsoft 365 and stalled by something fixable, yes, and we'll fix it there. Leave when it has become the system and the platform's limits or its cost are what's holding it. Q: How long does moving off Power Apps take? A: It depends on how many screens, flows and data sources there are, which the assessment counts. The shape is the usual one: the first process running on your data in staging within about six weeks, then one at a time until Power Apps can be switched off. --- # Finishing a stalled Replit app URL: https://www.solvewithsoftware.com/rescue/replit Title: Finish a Stalled Replit App Description: Replit built most of your app. The code exports, the database, secrets and hosting don't. We move it all to infrastructure you own. From £395 + VAT. Last reviewed: 2026-09-04 A Replit app is a real full-stack codebase, usually Node or Python, and it exports cleanly by zip or GitHub. What doesn't export is the platform around it: Replit's database, file storage, secrets and hosting, which the app depends on without anyone having decided to. Solve With Software takes the code into your own repository, gives it a database, hosting and secrets you control, puts the foundations under it and finishes it one feature at a time, on a fixed price from the assessment. ## What Replit gives you A working app, quickly, in one place. Replit Agent writes the front end and the back end, installs the packages, sets up a database and deploys it, all inside Replit's browser-based environment. Nothing has to be installed on anyone's machine, which is why it's so easy to get a long way in a weekend. The code it writes is ordinary. Node or Python on the server, React or plain HTML in front, a PostgreSQL database or Replit's own key-value store behind. Getting it out is a menu option: download as a zip, or push to GitHub. ## What Replit keeps Everything the code leans on. The database is Replit's. The file storage is Replit's. The secrets, the API keys for whatever the app talks to, live in Replit's secrets manager. The always-on hosting, the domain, the scheduled jobs and the logs are all Replit deployments. None of that is wrong for a prototype. It's why a Replit app that leaves Replit stops working: the code is fine, and it's reaching for a database and a set of secrets that aren't there. Taking a Replit app over is mostly the job of giving it a home of its own. ## What's usually missing - **A database you own.** With a backup that's been restored, not a platform store nobody has tested exporting from. - **Environment separation.** One app, one database, and it's live. No test copy, no staging. - **Security.** Agent-built back ends often trust every request. Login exists; authorisation, the part that stops one user seeing another's data, often doesn't. - **Error handling and retries.** It works when the API on the other end answers. Real systems spend most of their effort on when it doesn't. - **Scheduled and background work.** The nightly job that runs while the app is "always on" has no equivalent yet outside Replit. - **Dependencies pinned to nothing.** Packages at whatever version was current on the day, with no lock file anyone has looked at. ## Finish it or rebuild? **Usually finish. The code exports, the language is mainstream, and the structure is often reasonable.** The work is a home of its own (repository, database, hosting, secrets), then foundations (test and staging environments, authorisation, integrity, error handling), then the unfinished features in order of value. Rebuild when the code is a single file that grew, or when the data model would have to change so much that patching costs more than replacing. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the code. ## How we take a Replit app over 1. **Push to GitHub**, into a repository in your organisation. The code now exists outside Replit. 2. **Read it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment): every route, every table, every secret the app reaches for, every outside service it calls, every scheduled job. 3. **Give it a home.** A database you own, with the data moved from Replit and reconciled. Hosting in your accounts. Secrets in a store you control. Scheduled jobs on a scheduler that exists. 4. **Foundations.** A test environment and a staging environment. Authorisation checks on every route. Constraints and transactions where the data needs them. Pinned dependencies. A backup that's been restored. 5. **Finish the features**, one at a time, each priced before you commit. Replit itself can stay in the picture for prototyping. It stops being where the business runs. ## Your data It moves once, and it never meets a change until the change has proven itself somewhere else. The move out of Replit's database is tested against a copy in a test environment, then run in staging with record counts and a sample reconciled. Only when the tests have shown it's safe does anything connect to live, and the Replit deployment stays available as a fallback until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Replit app it reads the code, maps everything the app depends on inside Replit, and prices the move and the finish as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Give it a home, then make it safe, then finish it. Marc Allington builds with AI tooling daily and has taken over enough hand-written systems to tell quickly what a generated codebase has and hasn't got. Everything we finish runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment. ## What we check first in a Replit build In order, on the first pass of the assessment: 1. **Does it run outside Replit?** Pushed to GitHub, installed on a clean machine, started. Usually the first failure is a missing secret or a Replit-specific database call. 2. **What does it reach for?** Every environment variable, every Replit service, every outside API. 3. **Who can do what?** Every route tested as a logged-out user and as the wrong user. 4. **The data.** What's in Replit's database, how it comes out, and whether it holds together. 5. **Background work.** Scheduled jobs, always-on processes, anything that runs when nobody's looking. 6. **Dependencies.** What's pinned, what's abandoned, what has a known vulnerability. 7. **Backup and restore.** Tried, not assumed. The report scores each, says what it means for finishing versus rebuilding, and prices both. ## Questions Q: We downloaded the code and it doesn't run. Why? A: Because it's reaching for Replit: the database, the secrets, the file storage, a scheduled job. The code is usually fine. It needs a home of its own with those things in it, which is most of the takeover. Q: Can we keep hosting it on Replit? A: You can, and for a prototype it's fine. For a system the business depends on, hosting and data you don't control are the risk the assessment will flag first. Usually the answer is to move the running app and keep Replit for experiments. Q: Our app is Python. Does that matter? A: No. Replit Agent writes Node or Python depending on the prompt, and both are mainstream. The takeover is the same shape: repository, home of its own, foundations, then features. Q: How do we get our data out of Replit? A: PostgreSQL data exports as a standard dump and moves to a database you own. Replit's key-value store needs a small script. Either way it's tested on a copy and reconciled in staging before anything switches. Q: Is it secure enough to put customers on? A: Assume not until it's been tested. Agent-built back ends often check that you're logged in and not what you're allowed to see. Authorisation on every route is on the first-pass checklist. --- # Finishing a stalled v0 app URL: https://www.solvewithsoftware.com/rescue/v0 Title: Finish a Stalled v0 App Description: v0 makes polished Next.js screens fast. What's missing is the system: data, rules, security. We turn the prototype into a real app. From £395 + VAT. Last reviewed: 2026-09-04 A v0 app is the least stuck of the AI-built apps we see, because v0 is a user-interface generator and honest about it: the Next.js screens it writes are good, exportable and yours. What's missing is everything behind them. Solve With Software keeps the screens, designs the data model and the rules they imply, builds the back end, and finishes it one feature at a time, on a fixed price from the assessment. ## What v0 gives you Screens, and good ones. v0 writes Next.js with Tailwind and the shadcn/ui component library, which is the same stack a lot of professionally built web applications use. The code is meant to be taken out: copy it into a project, or export and deploy it wherever you like. Since February 2026 v0 has had Git integration, an editor, database connectivity and agent-style workflows, so a v0 project can go further than a set of components. It rarely goes as far as a system. A typical stalled v0 app has a convincing dashboard, forms that look right, tables full of sample data, and nothing underneath that a business could run on. ## What v0 doesn't give you The part that takes the time in any business application: - **A data model.** The screens imply one. Nobody has designed it. - **Business rules.** Who can approve what, what happens when a quote is accepted, what a valid order is. The screens have buttons for these and no logic behind them. - **Real data.** The tables show placeholder rows. Connecting them to a database is the moment the project usually stalls. - **Security.** Login screens exist; authorisation, sessions and permissions usually don't. - **Integrations.** The sync with Xero, the email, the payment. - **The boring layer.** Error handling, validation, logging, tests, staging, backups. None of that is a criticism of v0. It was built to produce interfaces, and it does. ## Finish it or rebuild? **Keep the screens, build the system.** The front end is usually worth keeping as it is, and it's the specification for the back end: every screen says what data it needs and what actions it offers. The work is designing the data model those screens imply, building the back end and the rules, connecting the screens to real data, and then finishing the features in order of value. Because the stack is Next.js, the back end can live in the same project, which keeps things simple. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the code. ## How we take a v0 app over 1. **Export to a repository in your organisation**, and confirm it builds on a clean machine. It nearly always does. 2. **Read the screens as a specification.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) lists every screen, the data it shows, the actions it offers, and the rules those actions imply. That list is the design of the system. 3. **Design the data model** from that list, and set up a database you own. 4. **Build the back end.** Rules, authorisation, validation, the integrations the screens assume, with secrets in a store you control. 5. **Connect the screens to real data**, one at a time, and finish the features in order of value, each priced before you commit. 6. **Foundations throughout.** Test and staging environments, error handling, logging, a backup that's been restored. ## Your data Usually there isn't any yet; the tables are showing sample rows. Where real data exists, it never meets a change until the change has proven itself somewhere else: tested on a copy in a test environment, then run in staging with the data reconciled, before anything connects to live. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a v0 app it turns the screens into a specification and prices the system behind them as fixed numbers. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it The screens are the specification; the system is the work. Marc Allington builds with AI tooling daily, including v0, and builds on Next.js, so the stack is familiar. Everything we build runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment. ## What we check first in a v0 build In order, on the first pass of the assessment: 1. **Does it build on a clean machine?** Almost always yes. 2. **Which screens are connected to anything?** Each table and form traced to real data, sample data, or nothing. 3. **What data model do the screens imply?** Every entity, field and relationship the interface assumes. 4. **What rules do the actions imply?** Every button that changes something, and what would have to be true for it to be allowed. 5. **Login, sessions and permissions.** What exists, what's decorative. 6. **What the app assumes exists outside itself.** Payments, email, storage, external systems. 7. **Where it would run**, and what it would cost to run there. The report turns that into a specification, a data model and a fixed price for building the system. ## Questions Q: Why did it stall? The screens are all there. A: Because screens are the part v0 does. The moment the app needed real data, rules and permissions, it needed a system, and that's a different job from generating an interface. It's also the job we do. Q: Can we keep the design exactly as it is? A: Mostly, yes. The screens usually survive with small changes where the real data doesn't fit the sample data. That's one of the reasons a v0 app is a good starting point. Q: Do we have to host on Vercel? A: No. Next.js runs on Vercel well and on other hosts too. Where it runs is decided on cost, data location and what else you run, and it's your account either way. Q: Can our team keep using v0 for new screens? A: Yes. With the code in your repository and a real back end behind it, v0 becomes a good way to draft new screens, which we then wire to the system and review. Q: How long to turn it into a working system? A: It depends on how many entities and rules the screens imply, which the assessment counts. The shape is the usual one: a first process working on real data within about six weeks, then one at a time, each priced before you commit. --- # When Zapier or Make automations became the system URL: https://www.solvewithsoftware.com/rescue/zapier-make Title: Zapier or Make Automations Takeover Description: Zaps or Make scenarios that became the system, failing quietly. Every automation mapped, then a system that owns the process. From £395 + VAT. Last reviewed: 2026-09-04 A business running on Zapier or Make has its rules spread across dozens of triggers, filters and steps that one person set up and nobody has written down. Solve With Software takes that over by building an inventory of every automation, what it does and what it depends on, then building a system that owns the process, with a database, rules in one place and a log, and keeping Zapier or Make for the edges where they're the right tool. The automations keep running until each process has proven itself, on a fixed price from the assessment. ## How it happens A form feeds a sheet. A Zap copies the row into the CRM. Another creates the invoice in Xero, another emails the customer, another posts to Slack when it's paid. Each one took an afternoon. The chain grows that way until nobody can list it, all in one person's account, with the business logic in the filters and formatter steps. It shows up as a system when something fails. A step errors for a week before anyone notices. A rate limit stops half the orders. A task or operation allowance runs out mid-month and the bill jumps. The connected Google account belongs to someone who's left. And nobody can answer the question "what happens when an order comes in?", because the answer is spread across every one of them. ## What you can take out - **The definitions.** Zapier exports every Zap as a JSON file from the account settings, and Make exports each scenario as a blueprint. Both describe triggers, steps and settings. Neither runs anywhere else, and neither imports into the other, so a move between platforms or into a system is a rebuild from the map. - **The history.** Both platforms keep a run history, which tells us the real volumes, the real failure rate and which automations haven't fired in a year. - **The data.** It isn't in Zapier or Make at all; it's in the sheets, the CRM, Xero and the mailboxes the automations connect. That's the point: nothing owns it. - **The connections.** Every app account the automations log in as, and who those accounts belong to. ## What's usually missing - **A record.** There's no single place where an order, a job or a customer exists with its status. There's a row in a sheet, a card in the CRM and an invoice in Xero, and they disagree. - **Rules in one place.** The same decision is made in three Zaps slightly differently. - **Failure handling.** A step that errors stops the chain, quietly. Replay is manual. - **A test environment.** Every change is made on the live automations. - **Ownership.** One person's login, one person's app connections. - **A log a human can read.** The run history shows a step failed; it doesn't say which customer didn't get their invoice. ## Keep the automations, or build a system? **Keep them for the edges.** Zapier and Make are good at connecting two apps that don't know about each other, and a system we build will still use them for that, or call the same APIs directly. **Build a system for the process.** When there's a thing the business tracks through stages, with rules about who does what and when, it needs a record and one place the rules live. That's a small application with a database, and the automations become its inputs and outputs rather than its logic. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the inventory. ## How we take it over 1. **Inventory.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) lists every Zap or scenario: trigger, steps, filters, code steps, the accounts it uses, who owns them, the last time it ran and how often it fails. Exports and run history make this factual rather than remembered. 2. **Map the process.** From the inventory, what happens to an order, a job or an enquiry from start to finish, and which automations touch it. This is the specification. 3. **Move ownership.** Connections and accounts into ones the business owns, before anything else changes. 4. **Build the system** that owns the record and the rules, with a log, a test environment and staging. 5. **Run it alongside.** The system shadows the automations on live volume, and the results are reconciled. Then automations are switched off one at a time as the system takes each step. 6. **Keep the edges.** The Zaps or scenarios that still make sense stay, now triggered by the system or feeding it. ## Your data It lives in the connected apps, so the first job is reconciliation: the sheet against the CRM against Xero, to find which is right. The system is loaded from the agreed source, tested against a copy in a test environment, then run in staging alongside the live automations with results reconciled, before anything switches. The automations stay switchable back on until you're confident. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an automation estate it produces the inventory and the process map, and prices the system as fixed numbers, alongside what the platforms cost a year at current volumes. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Inventory first, then a system for the process and automations for the edges. Marc Allington builds the systems these automation chains grow into, and integrates with the same apps directly. Everything we build runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment. ## What we check first in an automation estate In order, on the first pass of the assessment: 1. **How many automations, and how many have run this year.** Exports plus run history. 2. **Whose accounts.** Every connected app login, and whether the person still works here. 3. **Where the rules are.** Every filter, formatter and code step that makes a business decision. 4. **Failure rate**, and what happened to the records the failed runs were carrying. 5. **Volumes and cost.** Tasks or operations a month, and what the next tier costs. 6. **The record.** Where an order or a job exists with its status, and how many places disagree. 7. **What the business needs that a chain can't do.** Usually reporting, and knowing where things are. The report turns that into a process map and a fixed price for the system. ## Questions Q: Can we export our Zaps or scenarios? A: As definitions, yes: Zapier exports all Zaps as JSON from account settings, and Make exports a scenario as a blueprint. They describe the automations; they don't run anywhere else and don't import into each other. A rebuild works from the inventory, not the file. Q: Should we move from Zapier to Make, or to n8n? A: If the only problem is the bill, maybe, and it's a manual rebuild either way. If the problem is that the business logic lives in the automations, moving platforms moves the problem. The assessment says which you have. Q: Can we keep using Zapier or Make? A: Yes, for the edges. A system we build will trigger them and be triggered by them. What changes is that the record and the rules live in the system, so the automations are inputs and outputs rather than the logic. Q: Automations fail and nobody notices. Is that fixable? A: Partly on the platforms, with alerts and replay. Properly, with a system that logs every step against the record it was carrying, so a failed run says which customer and what's missing. Q: How long does this take? A: It depends on how many automations there are and how many processes they add up to, which the assessment counts. The shape is the usual one: the first process running in the system alongside the automations within about six weeks, then one at a time. --- # Taking over a stalled Zoho Creator app URL: https://www.solvewithsoftware.com/rescue/zoho-creator Title: Zoho Creator App: Fix or Rebuild Description: Zoho Creator built in-house and stuck: over its limits, Deluge author gone. Fix in place or rebuild on technology you own. From £395 + VAT. Last reviewed: 2026-09-04 A Zoho Creator app is readable but not portable. Its structure and every Deluge script export as a .ds file, and a backup adds the data as CSV, but Deluge runs nowhere except Zoho. Solve With Software takes one over by reading that export and the data behind it, then deciding on evidence between fixing it in place, where Zoho fits, and rebuilding it on technology you own, where the platform's limits or its per-user cost are what stalled it. The data and the rules carry across either way, on a fixed price from the assessment. ## How a Zoho Creator app stalls Someone in the business built it, usually alongside Zoho CRM or Zoho Books, and it worked. Forms for the jobs, reports for the office, a few Deluge scripts to move things between them. Then it grew. The scripts multiplied and started to depend on each other. A report that was quick with a thousand records isn't with a hundred thousand. Each new person who needs to use it is another licence. Customers were promised a portal, which is another licence tier. The person who wrote the Deluge left, and the scripts are theirs. None of that is a failure of Zoho Creator. It's a tool for building small applications quickly inside the Zoho ecosystem, and the trouble starts when a small application becomes the system. ## What you can take out - **The structure and the logic, readable.** The application exports as a .ds file: every form, field, report, page, schedule and Deluge script. It runs nowhere but Zoho, but it's a full description of what the app does and it's the specification for whatever comes next. - **The data.** A backup, on the Professional edition and above, bundles the .ds file with a CSV per form. Records are also reachable through Zoho Creator's REST API, which is how a rebuild keeps both systems in step during the move. - **Attachments and files**, through the same backup and API. - **The connections.** What the app reads from CRM, Books or anything outside Zoho, which the scripts spell out. ## Fix it in place, or rebuild? **Fix it in place** when the app is small, close to the rest of Zoho, and stalled by something the platform can solve: a script rewritten, a report restructured, a schedule that fails quietly made to fail loudly. Zoho Creator is good at what it's good at, and we'll say so. **Rebuild on technology you own** when the app has become the system. Performance that doesn't recover, a per-user bill that grows with the business, customers or suppliers who need access, integrations that Deluge can't reach, or rules the platform can't express. The rebuild starts from the .ds file as a specification, keeps the data, and runs alongside the Zoho app until each process has proven itself. **Often both.** Stabilise it in place so it stops hurting, then move the processes that outgrew it. The general keep, finish or replace reasoning (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) applies, and the assessment makes the call from the export and the data. ## How we take a Zoho Creator app over 1. **Export the application and take a backup**, so its definition and its data exist somewhere you control, dated. 2. **Read it.** The assessment (https://www.solvewithsoftware.com/legacy-system-assessment): every form, every report, every Deluge script and what it calls, every schedule, every connection to the rest of Zoho, and the licences each part needs. 3. **Read the data.** How many records, how clean, and how it comes out. 4. **Decide**, from evidence, per process: fix in place, or rebuild. 5. **Rebuild alongside**, where that's the answer. The new system runs in staging on the migrated data, checked by the people who use it, reconciled, then switched process by process. The Zoho app stays until the last one has moved. 6. **Or fix in place**, priced as its own stage, with the same test-then-live discipline. ## Your data It comes out of Zoho once as CSV, checked, and never meets a change until the change has proven itself somewhere else. The migration is tested against a copy in a test environment, then run in staging with every form and record count reconciled, before anything connects to live. Where the app shares data with Zoho CRM or Books, that link is rebuilt on Zoho's APIs so the two keep agreeing. ## What it costs The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Zoho Creator app it reads the export, the scripts and the data, and prices fixing in place and rebuilding as fixed numbers, alongside what the current licensing costs a year. What drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## How we approach it Read the export before deciding anything, and be willing to say the platform is fine. Marc Allington builds the web and .NET systems that apps move to when they outgrow a builder, and reads Deluge as one more scripting language. Everything we build runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment, and no per-user licence. ## What we check first in a Zoho Creator build In order, on the first pass of the assessment: 1. **Is there an export and a backup?** If not, that's the first step, and it's Zoho's own feature. 2. **Every Deluge script**, what triggers it, what it changes, and which other scripts it depends on. 3. **Reports and their record counts.** Where the app is slow and why. 4. **Licences.** Which edition, how many users, whether a portal is in play, and what that costs a year. 5. **Schedules and integrations.** What runs unattended, what it talks to, and whether it tells anyone when it fails. 6. **Who can do what.** Permissions in the app and what the forms allow underneath them. 7. **What the business needs that the platform can't do.** Often the reason it stalled. The report sets out fixing in place and rebuilding side by side, with a fixed price on each. ## Questions Q: Can we export our Zoho Creator app? A: The definition, yes, as a .ds file with every form, report and Deluge script in it, and the data as CSV through a backup on the Professional edition and above. The definition only runs on Zoho, so a rebuild uses it as the specification rather than as code that moves. Q: The person who wrote the Deluge scripts has left. Can you read them? A: Yes. Deluge is a readable scripting language and the export contains every script. The assessment turns them into a plain list of rules, which is what the business needs whether the app stays on Zoho or not. Q: The per-user cost keeps rising. Is that fixable? A: Sometimes, by trimming who needs a licence or which edition. Often not, because the app needs what the higher tier does. A rebuild on technology you own has no per-user licence, which is one of the numbers the assessment puts side by side. Q: Should we stay on Zoho Creator? A: If the app is small, close to the rest of Zoho and stalled by something fixable, yes, and we'll fix it there. Leave when it has become the system and the platform's limits or its cost are what's holding it. Q: How long does moving off Zoho Creator take? A: It depends on how many forms, scripts and connections there are, which the assessment counts. The shape is the usual one: the first process running on your data in staging within about six weeks, then one at a time until the Zoho app can be switched off. --- # Systems we modernise, by sector # The systems we modernise, by what they do URL: https://www.solvewithsoftware.com/systems Title: Systems We Modernise, by Sector Description: The business systems we take over and modernise, Old Guard and New Legacy, sector by sector, and where AI helps on each. From £395 + VAT. Last reviewed: 2026-09-14 Most owners know what their system does long before they know what it is built in. Solve With Software describes here the kinds of business system it takes over and modernises, sector by sector, so you can find the one that looks like yours and see what modernising it brings. Each page covers both generations of the system, the Old Guard built in the 2000s and the New Legacy built since 2016, and what AI could take off the desk once it is safe to change. ## The Old Guard and the New Legacy Every system described here comes in two generations, and a business usually has one of them. **The Old Guard** was built somewhere between 2000 and 2013, by a contractor, an employee who has since left or a small local firm, on the desktop tools of the day: Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6), Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access), Delphi (https://www.solvewithsoftware.com/modernise/delphi), Classic ASP (https://www.solvewithsoftware.com/modernise/classic-asp), with the data in SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) and Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports) for the paperwork. It runs on a PC in the office or a server under the stairs. The person who built it has retired or moved on, nobody has changed the code since, and that is why it still works and why nobody dares touch it. **The New Legacy** is the same system built from about 2016, by a small agency, a freelancer or someone in the office on a low-code builder: a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) or PHP (https://www.solvewithsoftware.com/modernise/php), something put together in Bubble (https://www.solvewithsoftware.com/rescue/bubble) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps), usually with a phone app beside it. It opened in a browser and felt like the future. Then the agency moved on, the hosting ended up on somebody's card, the versions fell years behind and the app stopped installing on new phones. Since 2023 there is a newer strand again: the system an office built most of the way in an AI builder (https://www.solvewithsoftware.com/rescue), which stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) before the last part came. The New Legacy is newer than the Old Guard and every bit as stranded. The work on both starts in the same place: make it safe to change, then modernise it one process at a time with the old system as the fallback. Plenty of businesses in these sectors run a bought package instead, and some have customised one so far that it can no longer be upgraded, or bolted a homegrown system beside it for the part the package never did. Those are the same problem in a different shape, and the system pages cover them where they are common. ## Where AI comes in **In the paperwork and in the records the system already holds, once it is safe to change.** On systems like these, most of the time AI can give back is spent retyping things that already arrived in writing: the booking in an email, the supplier's PDF, the photo of a signed sheet, the handwritten timesheet. AI reads them and drafts the entry for someone to check rather than type. Past the paperwork, it works on the records. It answers the question no report was ever written for, in plain words, with the records behind the answer shown so a person can check them. Its access is read-only, so asking a question never changes a record. It reads years of notes on a site, a vehicle or a matter and puts the few lines that matter at the top. And it holds back the order, the booking or the sign-up that does not look like the others, before it costs anything. How much time that gives back depends on the volumes, so each system page works it out for a typical business of its kind, names where AI pays back first, and names one place where it is not worth doing. It comes after the first stage, because nothing can be added safely to a system that cannot be changed safely. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back on the system as it stands. ## Questions Q: How do we know whether ours is Old Guard or New Legacy? A: Mostly by when it was built and how it is opened. A Windows program or an Access database installed on the office PCs, built by about 2013, is Old Guard. A system that opens in a browser or runs as an app, built by an agency, a freelancer or on a builder since about 2016, is New Legacy. Plenty of businesses have one of each, joined together, and the free consultation works out which is which. Q: Our system is only a few years old. Can it really be legacy already? A: Yes. A system becomes legacy when nobody can safely change it, not at a particular age. A 2020 web system whose agency has gone, whose hosting nobody controls and whose versions are years out of date is as stuck as a 2005 Access database, and often harder to hand over because nobody has the passwords. Q: What could AI save a business like ours? A: Time on the paperwork, first. On the systems these pages describe, AI reads the emails, PDFs and photographs that someone currently retypes, and drafts the entry for a person to check. After that it answers questions from the system's own records, read-only, and flags the entries that do not fit. How much time it gives back depends on the volumes, and each system page works that out for a typical business of its kind. The assessment says where it would pay back on your system before anything is built. Q: Our system is not on any of these pages. Is it still the kind of work you do? A: Usually. These pages describe the systems that come up most often, and most business systems are a mix of them. The free one-hour consultation works out what yours does and what it is built in, and the assessment is sized to it. Q: What does modernising a system cost? A: It depends on the system, but it does not take long to get a price and a plan to you. The assessment is from £395 + VAT, with an exact price before you commit, and produces a report with costed options and a fixed price for each. The report is yours. Take it to us, another developer, or nobody. --- # Systems that run transport and logistics businesses URL: https://www.solvewithsoftware.com/systems/transport-logistics Title: Transport and Logistics Systems Description: The systems that run haulage, logistics and skip hire firms, old and new, dispatch board to skip yard, and where AI helps on each. From £395 + VAT. Last reviewed: 2026-09-14 Transport and logistics businesses, from hauliers and warehouses to skip and waste yards, run on systems built for one fleet, one depot, one port or one yard, usually years ago and usually by someone who knew the trade. Solve With Software takes those systems over and modernises them in stages, so the traffic desk keeps the screen it knows while the drivers, the customers and the accounts get connected to it, and AI takes the retyping of bookings and paperwork off the desk. The pages below describe the kinds of system we see, in both their generations, and what modernising each brings. ## Where these systems run Haulage firms, container hauliers, third-party warehouses and skip and waste yards run systems like these all over the UK, from the ports to the distribution parks of the Midlands and the North. Nearer home they include the hauliers working Felixstowe and Harwich, the depots along the A12 and A14, and the skip yards on the estates between them. The skip hire and waste collection system (https://www.solvewithsoftware.com/systems/field-services/skip-hire-waste-collection-system) is listed here as well as under field services, because a yard with its own lorries runs as much like a haulier as a service firm. Each has a system at its centre that was built for the way that one business works, and each has the same question about it: how do we move it forward without stopping the trucks? We are based in Colchester and take on systems anywhere in the UK. The work runs remotely wherever the business is, with someone on-site across Essex, Suffolk and London when the system needs it, and the regional page (https://www.solvewithsoftware.com/essex-suffolk-london) says how the local side works. ## The Old Guard, the New Legacy, and the package beside them Each of these systems turns up in two generations, and most offices have one of them. **The Old Guard** was written between the early 2000s and about 2013, usually by a contractor who knew the trade. The haulage dispatch board (https://www.solvewithsoftware.com/systems/transport-logistics/haulage-dispatch-system) is a Windows program in Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) or Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access); the container booking system (https://www.solvewithsoftware.com/systems/transport-logistics/container-haulage-booking-system) is an Access front end and a .NET traffic screen sharing one SQL Server database; the compliance records (https://www.solvewithsoftware.com/systems/transport-logistics/fleet-maintenance-compliance-system) are a transport manager's Access database with a coloured planner beside it. They run on a server in the depot office. **The New Legacy** was built from about 2016 by an agency or a freelancer, as a browser system with a drivers' app, or in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or Zoho Creator by someone in the office. Since 2023 a few offices have tried again in an AI builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app). It opens anywhere, and nobody left in the business can change it. Plenty of fleets and third-party warehouses run a bought transport or warehouse (https://www.solvewithsoftware.com/systems/transport-logistics/warehouse-stock-system) package instead, with a homegrown piece beside it for the part the package never did. That piece is the same kind of work. ## What modernising them usually brings Three things, whatever the system. The drivers and the customers get connected to it: PODs from a phone, live tracking against the load, a customer login in place of the spreadsheet someone updates by hand. The office gets off the one PC: a supported database, a backup that has been restored on purpose, a board that opens from home. And the business gets paid sooner, because the paperwork that used to take two days to reach the invoice arrives the same afternoon. Once the system is safe to change, AI takes the retyping off the desk as well: the booking read from the forwarder's email, the POD matched to its job, the inspection sheet read into the record. Each system page works out what that gives back at the volumes a typical office of its kind handles. None of it needs the old system switched off. Each piece is added beside it, on the same data, and the office switches when the new screen is better than the old one. ## Questions Q: Do the trucks stop while the system is modernised? A: No. The old program keeps running and each new piece is built beside it, on the same data: the driver's phone, the customer login, the board in a browser. The traffic desk moves to a new screen when it is better than the old one, and the old one stays open until then. Q: Our rates and the rules about which truck goes where are in the system and nowhere else. Do they survive? A: They are the first thing found. Rate tables, site restrictions, free-day counting and each customer's invoicing exceptions come out of the code with the people who use them, get written down, and go into data the office can see and change. A rewrite from scratch is where rules like these get lost, which is why the old system stays running. Q: The person who wrote our system has retired. Can it still be taken on? A: Yes, and that is the usual starting point for systems like these. The first job is finding the source code, or recovering what can be recovered, and putting it under version control with a test copy beside the live one. From there the rules are read out of the code with the people who use the screens, and written down, often for the first time. Q: Can AI do anything useful with a system as old as ours? A: Yes, once the system is safe to change, and in the paperwork rather than the planning. On systems like these it reads what already arrives in writing, the booking email, the delivery note, the inspection sheet, the line's invoice, and drafts the entry for someone to check rather than type. On a desk keying a few hundred loads a day, the bookings alone are most of that time. It comes after the first stage, because nothing can be built safely on a system that cannot be changed safely, and the assessment maps where it would pay back on the system as it stands. Q: What does it cost, and how long before we see something working? A: The assessment is from £395 + VAT, with an exact price before you commit, and it produces a report with costed options and a fixed price for each. The report is yours. Take it to us, another developer, or nobody. After that, the first stage usually has something working within about six weeks, and each stage is priced before you commit to it. --- # The booking system that runs your container haulage URL: https://www.solvewithsoftware.com/systems/transport-logistics/container-haulage-booking-system Title: Container Haulage System Modernisation Description: A container haulier's booking system: boxes, port slots, free days, what modernising it brings and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A container haulage booking system knows where every box is and what it is costing: the booking, the port slot, customs and the release, the driver and trailer, the empty return and the free days ticking down. Solve With Software takes over booking systems built for one haulier years ago, keeps them running, and modernises them in stages, so the office keeps the screens it knows while the port slot, the free days and the driver's phone get connected to the same data. AI helps first with the forwarders' booking emails, drafting each box into the system for a clerk to check. The assessment prices each stage before you commit. The Old Guard: Access bookings by a contractor in the mid-2000s, a .NET traffic screen by a local developer around 2012, both on one Windows server in the office. The New Legacy: Built between 2016 and 2022 by an agency or a freelancer as browser bookings with a driver app, or on a low-code builder by a bookings clerk. Where AI helps: Forwarders' booking emails drafted in for a clerk to check: 80 to 250 boxes a day at two minutes saved on each comes to about three to eight hours a day. ## Inside a container haulage booking system Two screens: Bookings for the clerks and Traffic for the planner, with one database behind both. A typical business running one of these has 30 to 80 tractor units, a yard within reach of the port, and an office of five or six across bookings, traffic and accounts, moving between 80 and 250 boxes a day. Whether it was put together in 2006 or 2018, it does the same job, and the office runs on it the same way. In the office's words, the booking arrives from the forwarder by email and gets keyed in: container number, size, line and vessel, collection and tip addresses, the customs status, the release PIN, the return depot and the free days. The clerk books the slot on the port's booking site in another tab and keys the reference back. The planner puts a driver, unit and skeletal against it and prints the job sheet. The box moves through collected, delivered and returned, the invoice raises with the surcharge and any waiting time, and the month's invoices go to Sage. The rules it holds are the trade's: - Free days count from discharge for one line and from gate-out for another, and quay rent runs on the port's calendar, not the line's. - A 20ft box over a certain weight goes only on a sliding skeletal, and two named drivers will not take them. - One forwarder's rate includes two hours' waiting, billed in half-hours after that; another includes none. - An import box emptied near tomorrow's export collection is offered as a triangulation before an empty run goes out. - No box goes to a driver until customs has cleared it and the line has released it. The contract files say some of that. The system says all of it. ## The Old Guard: two front ends, one database Built in two halves, a few years apart. The bookings side was written in Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) in the mid-2000s by a contractor who understood merchant haulage. When the port's booking rules outgrew it, somewhere between 2010 and 2013, a local developer added a .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) program for the traffic screen and the port paperwork, moved the data into SQL Server (https://www.solvewithsoftware.com/modernise/sql-server), and left both front ends running against it. The export to Sage (https://www.solvewithsoftware.com/modernise/sage-integrations) goes at month end. All of it sits on one Windows server in the office, usually the same box the shared drive lives on, with the Access screens opened from the clerks' PCs. Neither developer is around now. The Access half is left alone because the .NET half reads the same tables, and the .NET half has no source anyone can find. It cannot be opened from the yard or from home, the port's slot lives in another browser tab, and the free days are a printout read at eight in the morning. ## The New Legacy: the same bookings, built around 2018 The same system built between 2016 and 2022, usually by a small agency or a freelancer, as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), PHP (https://www.solvewithsoftware.com/modernise/php) or early .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), or put together in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by a bookings clerk who had taught themselves the tool. The clerks book in a browser, the planner has a board on a wide screen, the drivers have an app of sorts that shows the next box, and the biggest forwarder has a login to watch their own. From the office it looked as though the port had been brought indoors. The free-days count is where it went wrong. It was written for the lines the haulier worked in 2018, all counting from discharge, so the line that counts from gate-out is tracked in a spreadsheet beside it, and the demurrage board promised for the second phase never arrived. The agency sent its last invoice long ago, and the driver app will not install on the phones the newest drivers carry. Hauliers who have had another go since 2023 with an AI app builder mostly got a booking screen that looked finished, then stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the port paperwork. ## Why does the office depend on it? **Because it is the only place that knows where every box is and what it is costing.** A container haulier lives on the gaps between events: the box discharged, the slot booked, the truck through the gate, the box tipped, the empty back at the depot. The system holds each of those against the booking, so a clerk answers a forwarder's "where's my box" from the screen rather than from a driver's phone. The job sheet carries the PIN, the slot and the return depot, which is what stops a truck being turned away at the gate with the day's plan behind it. The invoicing link is what makes the extras real. Waiting time, the surcharge, a second tip, an out-of-hours delivery: each is a line on the job, so it gets billed rather than remembered. And the demurrage report, run each morning, is the office's early warning on the boxes that will start costing money if nobody moves them. The office does not think of it as software. It is the way the job is done. ## Where it has started to cost money Systems like this do not break. The world around them changes. **The port and the lines moved to portals.** The slot, the release, customs clearance and the vessel's arrival each live on a website now, and the office keys them into the system by hand, several times a box. A mistyped container number fails the check digit at the gate and the truck comes back empty, the slot wasted and the next box late. **Free days run out on a report.** Either generation knows the free days, but the warning is a person reading a printout or a list at eight in the morning. A box that overstays turns up on the line's invoice weeks later and gets paid, because nobody can now prove when it left the port. **Two front ends, one set of rules, kept in step by hand.** The Access screens and the .NET program each carry a copy of the rate and surcharge logic. A change is made twice, and the month one copy was missed, a big account's invoices went out at the old surcharge and the credit notes took a fortnight. **The server it shares.** The .NET program and the database sit on a Windows Server 2012 box, which ended in October 2023. The insurer's questionnaire asks about it now, the IT company will not move it because the Access links break every time anyone tries, and so it stays. ## What changes when the bookings are modernised? **The same bookings, with the port, the free days and the driver connected to them.** Every one of these comes out of something the system already does. **The port booking made once.** The slot reference, the release PIN, the customs status and the container number live on the job. The number is checked against its check digit, and no driver is allocated until the box shows cleared and released. One keying, one place, and the errors behind the gate refusals go with it. **Free days on a countdown.** A board of boxes ordered by days of free time left, by each line's rules, with the return depot on every card. The planner books the empty run before the charge starts, and the line's invoice is checked against the system's own dates. **One set of rules, in data.** Rates, the surcharge, the waiting-time terms and the trailer restrictions come out of both codebases into screens the office owns. A change is made once and applies everywhere. **Waiting time with evidence.** The driver's phone stamps arrival and departure at the customer's gate. The extra goes on the invoice with the times beside it, and the argument about it mostly stops. **The traffic screen in a browser.** The planner's board opened in a browser on the same data, off the shared server or the hosting account nobody owns, from the yard or from home when a vessel is late on a Sunday. None of this switches the old system off, whichever generation it is. Each piece is added beside it. ## Where does AI earn its place in a container office? **In the paperwork the lines and the forwarders send, and the empty runs nobody had time to plan.** AI does the reading and the matching here, and the plan stays with the planner: **Bookings read from the forwarder's email.** The booking arrives as an email or a PDF, and a clerk keys the container number, the line, the vessel, both addresses, the PIN and the return depot. AI drafts the booking from it, and the clerk checks the fields against the email rather than typing them. At 80 to 250 boxes a day, with about two minutes of keying saved on each, that comes to about three to eight hours a day across the bookings clerks. **The lines' invoices read against the system.** The demurrage and detention invoice arrives weeks after the box went back, a PDF with a page of charges. AI reads each charge, matches it to the box and the system's own gate and return dates, and flags the ones that disagree. The clerk queries only those. A big line's invoice might carry 50 to 100 charges, and at about three minutes a charge to find the box and check its dates by hand, that works out at two and a half to five hours each time one lands. **Tomorrow's triangulations suggested.** From tomorrow's export collections and today's import empties, AI drafts the pairings for the planner to accept or bin. Reading the two lists side by side for the day's 80 to 250 boxes, at about 15 seconds a box, adds up to 20 minutes to an hour each evening, and that time goes back to the planner. **Questions the reports never covered.** "Which forwarder's boxes waited longest at the tip this quarter?" AI answers from several thousand jobs in plain words, reading them and changing none, and lists the boxes behind the answer for the office manager to check. A rate review raises four to six questions like it, and at about 40 minutes of filtering exports for each, that is two and a half to four hours of filtering before every review. Not worth doing: AI to book the port slots. Availability and the planner's knowledge of which driver can make which window decide it, and the port's own system has the last word. Each of these reads the bookings or drafts into them, so none starts until the first stage has made the system safe to change. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows where on this system AI would pay back first. ## The stages, and what goes first Stabilise first, then the pieces the office feels, with the old screens running throughout. 1. **Stabilise.** Source for both front ends, or for the agency's code, found or recovered. The database on a version that is still supported, on a server that is too, a backup restored on purpose, and a test copy so a change can be tried away from the live bookings. This goes first because the 2012 server, or the hosting account nobody owns, is the one thing that could stop the business overnight. 2. **Free days, customs and the port slot on the job.** The countdown board, the customs status and the slot reference in the booking, all writing into the existing database. 3. **The driver's phone.** The job sheet, the PIN and the return depot on a phone, with gate and tip times stamped as the driver goes. Paper sheets keep printing until nobody collects them. 4. **The traffic board in a browser, and the rules into data.** Rates and surcharge out of both programs into one place. Run beside the old screens until the planner stops opening them. 5. **Retire the old front ends** when nothing depends on them: the Access screens first and the .NET program after, or the agency's site in one go. The last to go is usually the month-end Sage export somebody trusts. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a booking system with two front ends that means a few days with the clerks, the planner and both codebases, finding where each rule lives and which copy is right, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a container haulage booking system takeover What the assessment establishes for a booking system with two front ends, and why each item matters: | Check | Why it matters | |---|---| | Is there source for both the Access front end and the .NET program, and does each match what is running? | Two front ends means two chances for the source to be missing. Without one of them, that half of the system can only be kept running or replaced. | | Which rules live where? | Rates in Access, the surcharge in the .NET code, the waiting-time terms in both. The assessment finds each copy and which one the invoices use. | | How are free days counted, per line, and where does the discharge date come from? | The countdown is only as good as its start date. If it is keyed from an email, the modernised board needs a better source. | | Which Windows Server and SQL Server versions, and what else runs on that box? | Windows Server 2012 ended in October 2023. A shared server means the move is planned around the other things on it. | | How do the port slot, the release and the customs status reach the job today, and is clearance checked before a driver is allocated? | They are the join between the system and the port. Where each is keyed by hand, or a box can be allocated before it has cleared, is where the wasted runs start. | | What does the driver's job sheet carry, and what happens when the PIN is wrong? | The sheet is the system's contract with the driver. Its fields become the phone screen. | | What feeds Sage, and does the invoice carry the surcharge and waiting time as lines or as one figure? | The export is tied to one Sage version and one invoice shape. It is tested before anything else moves. | | Which spreadsheets sit beside it? | The triangulation sheet, the trailer pool and the demurrage tracker are each a feature the system lacks, and each is a stage. | ## Questions Q: Do the clerks have to stop using the Access screens while this happens? A: No. Both the Access front end and the .NET program keep running on the same database, and each new piece is built beside them. The clerks move to a new screen when it is better than the old one, and the old one stays open until then. Q: Can the port's slot booking be linked so we stop keying it twice? A: Sometimes, and the assessment finds out. It depends on what the port makes available to hauliers and on how the booking is identified in the system. Even where no link is possible, holding the slot reference and the container number on one job, with the check digit tested, takes out most of the double keying that causes the gate refusals. Q: Can it work out demurrage and detention for us instead of the morning report? A: Yes. Each line's counting rule is written down with the clerks, put into data, and the board counts from it. The line's invoice is then checked against the system's own gate dates, which is where the charges worth disputing show up. Q: Our rates are in two programs and nobody is sure which is right. Where do you start? A: With that. Finding where each rule lives, which copy the invoices use and where the two disagree is the first job of the assessment, and the answer goes in the report. From there the rules come out of both codebases into screens the office owns, and a change is made once. --- # The system that keeps your fleet legal URL: https://www.solvewithsoftware.com/systems/transport-logistics/fleet-maintenance-compliance-system Title: Fleet Compliance System Modernisation Description: The system that keeps a fleet legal: inspections, defects, O-licence records, what modernising brings and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A fleet maintenance and compliance system holds every vehicle and trailer, its inspection planner, its defects and their repairs, the MOT and tachograph dates, and the driver records a DVSA examiner asks to see. Solve With Software takes over compliance systems built for one fleet years ago, keeps them running, and modernises them in stages, so the transport manager keeps the records that protect the O-licence while the drivers' checks arrive from the walkaround app and the planner plans itself. AI helps first with the workshop's inspection sheets, reading each into the vehicle record for the clerk to check. The assessment prices each stage before you commit. The Old Guard: Started in Access between 2005 and 2010 by the transport manager of the day, beside an Excel planner, and run on the compliance clerk's PC. The New Legacy: Built between 2016 and 2022 by a freelancer or small agency as a web system with a drivers' app, or on a low-code builder by a transport manager. Where AI helps: Inspection sheets and brake tests read into the record: eight to fifteen a week at a quarter of an hour's keying each comes to about two to four hours a week. ## What a fleet compliance system keeps track of One database, one planner on the wall, and one person who keeps both right. A typical business running one of these has 30 to 100 vehicles and trailers across one or two operating centres, a transport manager, a compliance clerk who owns it, and a workshop with two or three fitters or a maintenance contractor, handling 30 to 100 walkaround checks a day and eight to fifteen safety inspections a week. Whether it was started in 2007 or 2019, it does the same job, and the licence rests on it the same way. Many fleets buy a maintenance package instead. This page is about the records kept in-house, or beside a package that never fitted. In the clerk's words, it holds the vehicle register with each unit's inspection interval, MOT, tax, tachograph calibration and insurance dates. The planner shows inspections by week, coloured by hand. Inspection sheets come back from the workshop and get keyed in, defects found and work done; the drivers' defect books come in with the keys, or the checks sit in a walkaround app nobody connected, and both get keyed too. Driver records have their own screen: licence checks, CPC, card expiry, medicals. The reports feed the monthly review and the folder printed when DVSA rings. The rules it keeps are the ones the licence rests on: - Inspection intervals differ by vehicle, six weeks for units, eight for trailers, four for one that had a prohibition, and only the system knows which. - A safety-critical defect takes the vehicle off the road until a fitter signs it off, and the traffic desk sees it as unavailable at once. - A driver with points above a threshold has the licence checked quarterly, not twice a year. - Vehicle units are downloaded every 90 days and driver cards every 28, counted from the last download, not the calendar. The licence undertakings say what must happen. The system says how this fleet does it. ## The Old Guard: an Access database and a coloured spreadsheet Started in Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) between 2005 and 2010 by the transport manager of the day, on top of an Excel forward planner (https://www.solvewithsoftware.com/modernise/excel-to-system) that never went away, and extended a table at a time for the driver records and the tachograph download dates. The data moved to SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) when the file corrupted once too often, or when the dispatch system moved and took it along; in some offices it is still an Access file. It runs on the compliance clerk's PC, with the planner printed and pinned to the wall behind it, and there is no accounts link because nobody ever needed one. The person who built it has retired. The firm that supports the office PCs keeps the machine running and leaves the database well alone, so nothing in it has changed for years. It cannot be opened from the workshop or the yard, the drivers' checks reach it on paper, and the planner is coloured by hand. ## The New Legacy: the same records, built as an app in 2019 The same records built between 2016 and 2022, usually by a freelancer or a small agency, as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) or PHP (https://www.solvewithsoftware.com/modernise/php) with a drivers' app in React Native (https://www.solvewithsoftware.com/modernise/react-native) or Ionic (https://www.solvewithsoftware.com/modernise/ionic), or put together in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) by a transport manager who learnt the tool on the job. The drivers do their walkaround on a phone, the workshop has a tablet, the planner is a screen instead of a wall, and the transport manager opens it from home. The intervals broke it first. The freelancer wrote six weeks for units and eight for trailers into the code, so the vehicle on four weeks after a prohibition lives on a sticky note beside the screen. The drivers' app has not been updated since 2022, and since 31 August 2026 Google Play will not take an update unless it targets Android 16, which nobody is left to do. New starters whose phones will not run it are back on the paper book. Since 2023 a few transport managers have had another go with an AI app builder, and the result stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the records an examiner would ask for. ## What does the business rely on it for? **The O-licence, and a fleet the transport manager can see in one screen.** An operator's licence is a promise to keep records, and this is where the promise is kept. When an examiner asks for a vehicle's history, the clerk produces fifteen months of inspections, defects and repairs from one screen and one drawer. The transport manager opens it each morning and sees what is due, what is overdue and what is off the road, which is most of the job in one view. Defects are closed with a name against them. The driver reported it, the fitter fixed it, the date is there, and that chain is what an examiner follows. The driver screen answers the insurer without a search through files, and the whole thing has kept a fleet of this size legal for a decade without a software bill. ## Where it falls short now The records are right. The way they get there is the problem. **DVSA cannot read it.** Earned Recognition needs the maintenance and drivers' hours data to come from a system DVSA has validated, and an Access database with a coloured spreadsheet is not one. So the fleet is stopped at the roadside like any other, and a visit means printing everything for a week beforehand. **The walkaround check is on paper, or as good as.** On the older system it always was; on the newer one it is again, for every driver whose phone the app will not install on. Where the fleet bought a walkaround app, the checks sit on the app's own website and the clerk keys the defects across. The defect book comes back with the keys, the defect reaches the workshop when someone reads it, and the repair is a signature on a carbon copy. The gap between a nil-defect check on Monday and a tyre found on Tuesday's inspection is the gap an examiner asks about. **The PC it runs on lost Windows 10 support in October 2025.** The IT company will replace the machine but will not put Access on the new one, and the planner's macros only ran on the old Office. The workaround is to leave the old PC on and not touch it. **The planner is a spreadsheet, and the spreadsheet is a person.** The forward planner is coloured by the compliance clerk, and nobody else reads the colours. An inspection that slips is found at the next visit, not in the office. ## What would the fleet get from modernising it? **The same records, with the drivers, the workshop and the planner feeding them without the paper.** Each of these grows out of something the system already does. **Drivers' checks straight into the vehicle record.** The walkaround app the fleet already uses, or a bought one, sends each check and defect into the vehicle's record and onto the workshop's list, timestamped with its photo, the nil-defect recorded as firmly as the fault. Only where there is no app does a simple phone check write into the same database. **A planner that plans itself.** Each vehicle's interval in data, so inspections, MOTs, calibrations and tachograph downloads land on one planner that nobody colours in. What is due next week is a question the screen answers. **The examiner's folder on screen.** Fifteen months of inspections, defects and repairs per vehicle, shown, exported or sent in an afternoon, and held in a shape a recognised system could take. **Defects closed with evidence.** Photo, part, fitter and time on each one, and repeat defects visible by vehicle and by driver, which is what the monthly review is for. **Driver records with reminders.** Licence, CPC, card and medical dates on the same planner, with the points rule that sets the check frequency kept as it is. **Off the old PC, and off the hosting account.** The screens opened in a browser by the transport manager from the yard or the workshop, on a supported database the business controls, with a backup that has been restored. None of this switches the database off, whichever generation it is. It gets added to, and the old screens stay open until they are empty. ## Where would AI save the compliance clerk time? **In the workshop's paperwork, the drivers' checks that all look alike, and the monthly review nobody has time to write.** The judgement stays with the transport manager. AI takes the reading: **Inspection sheets and brake test printouts read into the record.** The contractor's sheet comes back as a PDF or a photo of a carbon copy, with the brake test printout stapled to it, and the clerk keys the defects found, the work done and the brake figures. AI reads both into the record, defects listed and figures in the right boxes, for the clerk to check against the sheet. At eight to fifteen inspections a week and a quarter of an hour's keying each, that comes to about two to four hours of the clerk's week. **Checks that do not fit the pattern.** Once the 30 to 100 walkaround checks a day reach the record, AI reads them against what the fitters find. A driver who has reported nil defects for three months on a unit that keeps failing its inspection, or a check finished in under a minute, is flagged for the transport manager to take up with the driver. Reading down that list at about 20 seconds a check works out at ten minutes to half an hour a day, and what is left to read is the few that stand out. **The monthly review drafted from the data.** Inspections done on time, defects by vehicle and by driver, repeat faults and overdue downloads, drafted from the system's own records for the transport manager to read, correct and sign. A month brings 35 to 65 inspections, and at about five minutes each to pull the defects, repairs and dates into the review by hand, that adds up to about three to five and a half hours before anyone counts the thousand or more checks. Not worth doing: AI predicting breakdowns for a fleet this size. The inspection interval and the fitter's judgement already do it, and no transport manager would put the licence behind a guess. An examiner can ask where any figure came from, so AI waits until the first stage has made the records safe to change. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back on this fleet's records. ## How the stages run Stabilise first, then the drivers' checks, with the old screens as the fallback throughout. 1. **Stabilise.** The Access file and the planner under version control, or the agency's code found and recovered, the data on a database version that is still supported, a backup restored on purpose, a test copy, and the old screens kept working on a supported PC. First because the licence depends on the records existing tomorrow, and the Windows 10 machine is the thing most likely to stop. 2. **The drivers' checks into the record.** The walkaround app the fleet already uses, or a bought one, connected so its checks and defects reach the vehicle record and the workshop's list the same day. Only where there is no app is a phone check added, writing into the same database. The paper books stay in the cabs until the drivers stop using them. 3. **The planner from data.** Intervals and dates out of the spreadsheet and the Access code into tables, the planner generated from them and still printed for the wall. 4. **The transport manager's screens in a browser,** the examiner's export and the driver records, each a stage priced on its own. 5. **Retire the old screens and the spreadsheet** when nothing depends on them. The last thing to go is usually the printed planner on the wall. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a compliance system that means a few days with the transport manager, the clerk and the workshop, finding where each interval and rule lives and what the examiner has asked for before, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a fleet compliance system takeover What the assessment establishes for a compliance system, and why each item matters: | Check | Why it matters | |---|---| | Is the data in an Access file or in SQL Server, and when was it last backed up and restored? | An Access file on a Windows 10 PC is the licence's records on one disk. Where it is, and whether a restore has ever been tried, comes before anything else. | | Where do the inspection intervals live: the licence, the spreadsheet or an Access table? | If the planner is the spreadsheet, the intervals are in a person's head and a colour code. They are written down before the planner is rebuilt. | | How does a defect get from the cab to the workshop, by book or by app, and how is the sign-off recorded? | The chain from driver to fitter is what an examiner follows. Where a walkaround app already holds the checks, whether they can be read out decides how they reach the vehicle record. | | Can fifteen months of records be produced per vehicle today, and how long does it take? | The answer is the measure of the examiner's folder. Where it takes a week, the export is the stage that pays back first. | | Which tachograph analysis software is in use, and does anything pass between it and the system? | Downloads and infringements usually live in a separate package. Whether it exports, and in what shape, decides whether the planner can count from the last download. | | Where are driver records held, and what rule sets the check frequency? | Licence checks, CPC and medicals are often half in the system and half in a folder. The points rule is one only the system knows. | | Which Windows and Office versions, and what breaks on a new PC? | Windows 10 support ended in October 2025. The Access runtime and the planner's macros are the usual casualties of a new machine. | | Who uses which screens: transport manager, clerk, fitters, traffic desk? | The clerk lives in it; the fitters and the traffic desk see slices of it, and each slice is a stage. | ## Questions Q: Will DVSA accept records from a modernised homegrown system? A: The Guide to Maintaining Roadworthiness asks for records that are complete, kept for at least fifteen months and produced on request; it does not name a product, and electronic records are accepted. Earned Recognition is a separate matter, because it needs the data to come from a system DVSA has validated. Some bought walkaround and maintenance apps come from providers DVSA recognises for the scheme, and whether the fleet's records could feed one is a question the assessment answers. Q: Do the drivers have to give up the paper defect books? A: No, and nobody sets a date for it. Checks from the walkaround app, or from a phone check where the fleet has no app, land in the same database the books are keyed into, so both work at once. Drivers move when the phone is quicker than the book, and the paper stays in the cab until then. Q: Our planner is a spreadsheet and only one person understands it. Is that a problem? A: It is the first thing written down. The intervals, the colours and the exceptions come out of the spreadsheet with the person who runs it, into data the system holds, and the planner is generated from that. The spreadsheet keeps being printed for the wall for as long as anyone wants it. Q: Can it link to our tachograph analysis software? A: Usually there is a way, and the assessment checks which. Most analysis packages export downloads and infringements in some form, and the planner can count from the last download date once it has that. Where there is no export, the download date is keyed once, on the day it happens, rather than tracked in the spreadsheet. --- # The dispatch system that runs your haulage fleet URL: https://www.solvewithsoftware.com/systems/transport-logistics/haulage-dispatch-system Title: Haulage Dispatch System Modernisation Description: The dispatch system that runs a haulage fleet: what it does, what modernising it brings, and where AI helps. Assessment from £395 + VAT. Last reviewed: 2026-09-14 A haulage dispatch system is the traffic desk's working memory: every load, who is collecting it, which vehicle, when it delivered and what to invoice. Solve With Software takes over dispatch systems that were built for one fleet years ago, keeps them running, and modernises them in stages, so the planners keep the screen they know while the business gets live tracking, PODs on a phone and invoicing the same day. AI helps first with the bookings that arrive by email, drafting each job onto the board for a planner to check. The assessment prices each stage before you commit. The Old Guard: Written between 2002 and 2012 by a contractor who knew the trade, in Visual Basic 6 or Access, and still running on a PC in the traffic office. The New Legacy: Built between 2016 and 2022 by a small agency or a freelancer as a browser board with a driver app, or put together on a low-code builder. Where AI helps: Booking emails drafted onto the board: a third of 80 to 300 loads at two minutes each works out to about one to three hours a day. ## What a haulage dispatch system does One screen, usually called Traffic or the Board, and one person who lives in it. A typical business running one of these has 20 to 60 vehicles, one or two depots, and a traffic office of two or three planners handling somewhere between 80 and 300 loads a day. Whether it was written in 2004 or 2019, it does the same job, and the office runs on it the same way. Plenty of fleets this size run a bought transport package instead. This page is about the other kind: the board written for one fleet, or a package customised so far that it can no longer be upgraded. In the planner's words, it takes the job from the customer's phone call or email, puts it on the board, allocates a driver and a vehicle, prints the run sheet and the delivery notes, records the POD when the paperwork comes back, and raises the invoice. Somewhere in it is a rate table nobody dares open, a subcontractor screen for the loads the fleet cannot cover, and a report the MD reads every Monday. The rules it holds are the reason it has lasted: - The rate for one supermarket contract is per pallet up to 26 and per load beyond it, except on a Friday. - Certain vehicles cannot go to certain sites, because of a low bridge, a weight limit, or a customer who banned a driver in 2016. - A job is not invoiceable until the POD is scanned, unless it is for the two customers who accept a signed run sheet instead. - A multi-drop job is priced as one load but reported as several deliveries, for the KPI the biggest customer measures. Nobody wrote any of that down. The system is the document. ## The Old Guard: the board built in the 2000s Written somewhere between 2002 and 2012 by a contractor who knew the trade, and extended every year since. A Windows program in Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) or Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access), with the data in SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) or an Access file, Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports) for the run sheets and delivery notes, and an export to Sage (https://www.solvewithsoftware.com/modernise/sage-integrations) on a Friday afternoon. It runs on a PC in the traffic office or a server in the comms cupboard, and it prints to the printer it has always printed to. The contractor has retired or moved away and the support contract lapsed years ago. Nobody has changed the code since, which is why it still works, and why nobody wants to be the first to try. It cannot be opened from home, it does not know where the truck is, and the POD comes back on paper. ## The New Legacy: the board built in 2019 The same board built between 2016 and 2022, usually by a small agency or a freelancer, as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) or PHP (https://www.solvewithsoftware.com/modernise/php), or put together in Bubble (https://www.solvewithsoftware.com/rescue/bubble) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by someone in the office who was good with that sort of thing. It opens in a browser, the drivers have an app of sorts, and the biggest customer has a login. From the traffic desk it looked like the future had arrived. What stopped this one is usually something the customers noticed first. The tracking was wired to the telematics box the fleet had in 2019, and when the fleet changed provider the trucks dropped off the board. The rate table only knows that year's customers, so every new rate waits for a developer the business no longer has. Meanwhile the agency has moved on, the code has stood still, and the driver app has quietly fallen off the newer phones. Since 2023 a few offices have tried again in an AI app builder and got as far as the driver's screen before the work stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app). In the traffic office, the planner now keeps the telematics provider's own map open in another window and checks each truck against the board by eye. ## What does it give the business? **A day of loads run by two people, and an invoice for every one of them.** The board is what lets a small traffic office run a fleet that would otherwise need twice the staff. The planner sees every load, every driver and every gap at once, and moves work with a few clicks. The run sheet the driver picks up at six in the morning comes out of the same screen, so what was planned is what gets done. The link to invoicing is the other half. Because the POD closes the job and the job feeds the invoice, the business bills every load it moves, at the right rate, and the weekly Sage export keeps the accounts within a week of the wheels. When a customer disputes a delivery, the answer is on the screen in ten seconds: who, when, signed by whom. That is why the system is still there. It fits how the office works, because it was built from how the office works. ## Where it starts to hold the business back Systems like this rarely fail. They stop keeping up. **The customers moved on.** The big accounts now want live tracking, an ETA, and a POD by email within the hour. The board knows where a load should be, not where the truck is, and the POD arrives on paper two days later. So the office keeps a spreadsheet beside the system for the customer portal, and someone updates it by hand. **It lives on one machine.** The system runs on the traffic office PC or the server in the cupboard, often on Windows Server 2016 with a SQL Server 2016 database. SQL Server 2016 updates ended in July 2026 and Windows Server 2016 follows in January 2027. Nobody wants to move it, because the last time it moved the printing stopped for a day. **The person who knew it has gone.** The contractor who built it retired or moved away, the support contract lapsed, and the firm that looks after the PCs will fix the printer but not the program. Small changes wait. Large ones are not attempted. **It cannot leave the office.** The planner cannot see the board from home, the drivers cannot see their jobs on a phone, and the transport manager keeps the defect books on paper because the compliance side never made it into the system. ## What does modernising it bring? **The same board, in a browser, with the rest of the business connected to it.** Each of these comes from something the system already does. **Live tracking on the board.** The vehicle's position from the telematics the fleet already pays for, shown against the load it is on. The planner stops phoning drivers for updates, and the customer gets an ETA without ringing. **PODs on the driver's phone.** Signature, photo and time at the point of delivery, in the office before the truck has left the site. The job closes, the invoice raises, and the two-day paper gap disappears. **Invoicing the same day.** With the POD in electronically, the weekly Sage batch can become a daily one, and cash arrives sooner. **A customer view.** The biggest accounts get a login to see their own loads, which takes the phone calls and the hand-updated spreadsheet out of the office. Same data, one place. **Off the one PC.** The database moves to a version that is still supported, on a server that is too, with backups that have been tested. The Cyber Essentials question stops being awkward. **The rules, written down.** The rate table, the site restrictions and the invoicing exceptions come out of the code into screens the office can see and change. A new planner learns the board in days. None of this needs the board switched off. It gets added to. ## What could AI take off the traffic desk? **The hours the office spends retyping what already arrived in writing.** AI earns its place on a dispatch system in the paperwork, not the planning. There are three places to start: **Bookings read from the email.** The customer's booking arrives as an email, a PDF or a photo of a delivery note, and a planner retypes it onto the board. AI reads it and drafts the job, with the collection, the delivery, the pallets and the reference filled in, for the planner to check. If a third of the 80 to 300 loads a day arrive that way, that is 27 to 100 bookings, and at two minutes' typing each it works out to about one to three hours a day. **PODs matched to jobs.** The paperwork that comes back is a signature on a crumpled sheet or a photo from the cab. AI reads the reference, matches the POD to the job and flags the ones that do not match. A week at 80 to 300 loads a day is 400 to 1,500 PODs. At half a minute each to find the job and tick it off, matching them by hand before the invoice run adds up to about three to twelve hours, and what is left is the handful that failed. **Queries answered from the board.** "Where is my load?" and "Did it deliver?" arrive by email all day. AI drafts the answer from the board's own data, with the job record it came from shown underneath, and the planner checks it and sends. At a query for one load in ten, that is 8 to 30 lookups a day, and at two minutes each to find the job and write the reply, it comes to between a quarter of an hour and an hour of the desk's day. Not worth doing: AI route planning for a fleet this size. The planner's knowledge of drivers, sites and the low bridge on the back road beats any model, and nobody in the office would trust the result. All three read from the board or write to it, so they wait until the first stage has made the board safe to change. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back on the system as it stands. ## How the takeover runs Stabilise first, then one process at a time, with the old system as the fallback. 1. **Stabilise.** Source code found or recovered, the database on a version that is still supported, a backup that has been restored at least once, and a test copy of the system so changes can be tried without touching the live board. This goes first because everything after it depends on being able to change the system safely, and because it takes the January 2027 deadline out of the conversation. 2. **PODs and the driver app.** The first new piece is the one the customers feel: a phone app for the drivers that writes into the existing database. The board does not change. The office watches PODs arrive during the day. 3. **The board in a browser.** The planning screen opened in a browser, on the same data, run alongside the old form until the planners choose to stop opening it. 4. **Tracking, the customer view, daily invoicing.** Each a stage, each priced on its own, each live in weeks. 5. **Retire the old program** when nothing still depends on it. The last thing to go is usually a report somebody loves. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a dispatch system that means a few days with the planners and the code, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a haulage dispatch system takeover What the assessment establishes for a dispatch system, and why each item matters: | Check | Why it matters | |---|---| | Is the source code available, and does it match the running program? | Without it, the options narrow to keep-running or replace. Dispatch systems were often built by one contractor, and the source may be on a laptop that left with them. | | Where does the rate table live, and who can change it? | Rates in code mean every price change is a developer change. Rates in data can be moved to a screen the office owns. | | Which database, which version, and where is it running? | SQL Server 2016 lost its updates in July 2026 and Windows Server 2016 ends in January 2027. An Access back end has a size ceiling a busy fleet may be close to. | | How does the POD close a job, and what happens when it doesn't? | The invoicing link is the most valuable part of the system and the most fragile. Its exceptions are the rules to preserve. | | What feeds Sage, and what happens when Sage upgrades? | The export is usually a file or a COM link tied to one Sage version. It gets tested before anything else moves. | | Which reports does the business run on? | Crystal and Access reports carry rules of their own. The Monday report is a specification. | | What talks to the outside: telematics, customer portals, order feeds, the fax line? | Each is an integration to keep working or replace. A customer's order feed or a fax-to-email box still on a phone line stops at the analogue switch-off on 31 January 2027. | | Who uses which screens? | The board is one screen. The accounts, the workshop and the MD each have others, and the stage order follows the people. | ## Questions Q: Do we have to stop using the board while it's modernised? A: No. The old program keeps running and the new pieces are built alongside it, on the same data. The planners switch when the new screen is better than the old one, and not before. Q: Our dispatch system is an Access database. Is that a problem? A: Not in itself. An Access front end with the data in an Access file is common, and the risk is the file's size and the way it handles several users at once. The usual first move is to take the data off the Access file and onto a supported database, leaving the screens alone, which the office does not notice except that it stops crashing. Q: Can we keep our rates and site rules? A: Yes, and they are the first thing found. They are the most valuable part of the system, and a rewrite from scratch is where they get lost. They come out of the code, get written down with the people who use them, and go into data the office can maintain. Q: Can it link to our telematics and to Sage? A: Usually. Most telematics providers have an interface the new board can read, and Sage integrations are common enough to have their own page. Electronic invoicing is due to become mandatory for business-to-business VAT invoices from April 2029, so the invoice link is checked against that too. The assessment checks which versions and which links are in play. --- # The stock system that runs your warehouse URL: https://www.solvewithsoftware.com/systems/transport-logistics/warehouse-stock-system Title: Warehouse Stock System Modernisation Description: A 3PL's homegrown stock system: locations, goods in and out, customer reports, what modernising brings and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A homegrown warehouse stock system holds every pallet by customer, batch and location, books goods in and out, drives the scanners on the floor, and produces the stock reports the customers run their own businesses on. Solve With Software takes over stock systems written for one warehouse years ago, keeps them running, and modernises them in stages, so the floor keeps the process it knows while the customers get a login, the scanners get replaced and the storage invoice comes out of the system. AI helps first at goods in, reading packing lists into the booking for a clerk to check. The assessment prices each stage before you commit. The Old Guard: A .NET Framework program on SQL Server, written by a local developer between 2008 and 2013, with SSRS customer reports, on the warehouse office server. The New Legacy: Built between 2016 and 2022 by an agency or a freelancer as a PHP web system with a scanner app on rugged phones, or on a low-code builder. Where AI helps: Packing lists read into goods in for a clerk to check: half of 300 to 1,000 pallets at half a minute each comes to about one to four hours a day. ## The stock system, screen by screen Stock Enquiry is the screen everyone has open. Goods In, Picking and Despatch belong to the scanners on the floor. A typical business running one of these has one or two warehouses with 8,000 to 20,000 pallet locations, 25 to 60 staff over two shifts, an office of four or five, and a dozen to thirty customers whose stock it holds, moving 300 to 1,000 pallets a day. Whether it was written in 2010 or 2019, it does the same job, and the floor runs on it the same way. Many 3PLs this size run a bought warehouse management package. This page is about the homegrown system, or the custom customer reporting bolted onto a package. In the office's words, a delivery is booked in against the customer's notice or the paperwork on the pallet, labelled and put away by scanner into aisle, bay and level. Orders arrive by email and CSV in whatever shape the customer sends, are keyed or imported, picked in waves, and go out with a despatch note and carrier label. At eleven each night every customer is emailed their stock, and on the first of the month someone turns the pallet count into the storage invoice in a spreadsheet. Each customer stayed for rules like these: - One customer's stock is picked oldest best-before first, another's oldest received first, and two customers ban part-pallets from the top level. - Storage counts pallets at midnight on Sunday for most accounts, on the last day of the month for one, and a half-pallet is a whole one for another. - Stock held pending the customer's quality check is charged for storage but never shows as available. - A pick short by more than one case goes to a supervisor before despatch. - A location blocked for damaged racking stays out of putaway until a named person clears it. Ask where those are written and the office points at the screen. ## The Old Guard: written for one warehouse around 2010 Written somewhere between 2008 and 2013 by a small local developer as a .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) program on SQL Server (https://www.solvewithsoftware.com/modernise/sql-server), to replace the Access database and the spreadsheets before it. SSRS (https://www.solvewithsoftware.com/modernise/ssrs) reports were added for the customers, one customer at a time, and the same program reaches the handheld scanners through a terminal session. It lives on a server in the warehouse office with the reporting server on the same box, and the office PCs open it from a shortcut on the desktop. The developer moved on some years ago and took the working knowledge with them. Changes stopped when they left, spreadsheets (https://www.solvewithsoftware.com/modernise/excel-to-system) have crept back in for the storage invoice and the stock count, and the scanners it was written for are no longer made. It cannot be opened from home, and the customers cannot see into it at all. ## The New Legacy: the stock system an agency built in 2019 The same system built between 2016 and 2022, usually by a small agency or a freelancer, as a web system in PHP (https://www.solvewithsoftware.com/modernise/php) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), with a scanner app in Ionic (https://www.solvewithsoftware.com/modernise/ionic) for the floor. Some were put together in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by an operations manager over a quiet winter. The office opens it in a browser, the customers have a login of sorts, and the scanners are ordinary phones in rugged cases. From the office it looked like the problem was solved for good. Despatch is usually where this one gives out. The label printing was wired to one courier's old booking link, and when the courier switched that off the despatch desk went back to the courier's own website, a parcel at a time. Each customer's report is a one-off page the agency wrote, so a new customer means a developer the business no longer has, and the agency itself has been bought and gone quiet. Since 2023 a few warehouses have tried an AI app builder for the customer portal, and it stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) once it had to count pallets by each customer's rule. So a customer signed since the agency went quiet gets their stock as a spreadsheet the office builds by hand each morning. ## What does the business get from it? **A warehouse that can find any pallet in seconds, and customers who trust the numbers.** A 3PL sells confidence. A customer hands over their stock and wants to know, each morning, what is there, what went out and what is on hold, without ringing. The nightly report answers that, and the fact that it has arrived at eleven every night for a decade is why the customer's own planning runs on it. Behind it, the scanner on the floor means the office knows what was done rather than what was planned: the pallet is where the system says it is. The other half is the storage invoice. Pallet-weeks by customer, each with their own counting rule, is where the margin lives, and the system's count is the only record of it. When a customer disputes the invoice, the answer is the movement history for that pallet. New customers come on without a new system, because the rules are per customer and the office has learnt where to put them. ## Where it now gets in the way Nothing in it is broken. What changed is what the customers and the floor expect. **The customers want a login and get a PDF.** The report goes out at eleven and the customer's planner wants live stock at ten in the morning, and to key their own orders. Instead, orders arrive as spreadsheets in every shape, and someone in the office re-keys them. Customers who sell online want web shop and marketplace orders out the same day with a courier label, and the system cannot take them in. **The scanners cannot be replaced.** On the older system the handhelds run Windows Mobile through a terminal session, and the program on the other end was written for that; on the newer one the scanner app was built for phones nobody sells now and will not install on the ones they do. Replacements come from auction sites, the batteries are worse each year, and there is no path to a handheld that can be bought new without a new program on both ends. **The reporting server lost its updates in July 2026.** SQL Server 2016, and SSRS with it, sit on the same box, and the nightly reports depend on it. The biggest customer's supplier audit now asks which version, and the answer costs points. **Month end is a spreadsheet only one person runs.** The pallet-week count comes out of the system, gets pasted in, and each customer's rule is applied by hand over three days. A wrong figure is argued for a fortnight, and nobody else has ever run it. ## What does modernising it give the warehouse? **The same stock ledger, with the customers, the scanners and the invoice connected to it.** Each of these is built on something the system already does. **Live stock for the customers.** A login showing their own stock, on hold and available, with order entry in place of the emailed spreadsheet. The nightly PDF keeps going for the customers who want it. **Scanners that can be bought new.** A handheld app on scanners that are still made, against the same database and running the same putaway and pick logic, so the floor's process does not change when the device does. **The storage invoice from the system.** Each customer's counting rule in data, the month-end figure ready on the first working day, and a dispute answered from the movement log instead of the spreadsheet. **Web shop orders in, courier labels out.** Orders from the customers' web shops and marketplaces land on the pick list without keying, and despatch prints the courier's label and sends the tracking back. **Goods in from the advance notice.** The customer's notice becomes the expected delivery, and the pallets are booked in by scanning against it rather than keyed from the paperwork. **Counts that do not stop the warehouse.** Cycle counts from the scanner during the shift, by aisle, in place of the weekend stock take on paper. **Reports off the unsupported server.** The SSRS reports on a reporting server that is still supported, or rebuilt, with the subscriptions the customers rely on kept running throughout. The old program stays running through all of it, whichever generation it is. Each piece is added beside it, on the same data. ## Which jobs could AI take off the warehouse office? **The paperwork at goods in, the orders that still arrive by email, and the stock questions no report answers.** AI takes what arrives in writing and what the office gets asked, and leaves the floor to the supervisor: **Delivery notes and packing lists read at goods in.** The pallet arrives with a packing list, a delivery note or a photo of a label, and a clerk keys the SKUs, the batches, the best-before dates and the quantities against the customer's notice. AI reads the paperwork and pre-fills the booking, and the clerk checks it against the pallet rather than typing it. If about half of the 300 to 1,000 pallets a day are coming in, that is 150 to 500 pallets, and at half a minute of line-by-line keying saved on each, it works out at about one to four hours a day for the goods-in desk. **Orders read from the customers who keep emailing.** Some customers will never use the login, and their orders keep arriving as spreadsheets and PDFs. AI reads each one into the order the system expects, flags a SKU it does not recognise, and the clerk approves the order rather than keys it. Where a handful of the dozen to thirty customers still email, say 10 to 20 orders a morning between them, two minutes of re-keying an order comes to 20 to 40 minutes each morning. **Questions no report answers.** "Which of this customer's pallets have not moved since March?" "Why did August's pallet count jump?" AI reads the movement log without changing it and answers in plain words, listing the pallets and movements behind the answer for the office manager to check before it goes to the customer. Questions like these come up six to ten times a month, and at about half an hour of one-off spreadsheet for each, that adds up to three to five hours, roughly half a day a month. Not worth doing: AI slotting for a warehouse this size. The supervisor knows which pallets belong where, and the racking rules the system already holds say what may not go on the top level. Nothing should read or write the stock ledger before it is safe to change, so AI waits for the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) finds where AI would pay back soonest in this warehouse. ## Stage by stage, with the old system as the fallback Stabilise first, then the scanners, because they are the thing most likely to stop the floor. 1. **Stabilise.** Source code found or recovered, for either generation, the database and the reporting server on supported versions, a backup restored on purpose, and a test copy to try changes against. First because the reports the customers depend on run on a server out of support, and because no new scanner can be pointed at anything until there is a test copy to point it at. 2. **The scanners.** A handheld app on scanners that are still made, against the same database, one process first, usually putaway. The old handhelds keep working beside it until the last one dies. 3. **The customer login.** Live stock and order entry on the same data. The nightly report keeps sending. 4. **Storage invoicing from the system.** The counting rules out of the spreadsheet into data, run in parallel with the spreadsheet for a month end or two. 5. **The office screens in a browser,** then retire the old program when nothing depends on it. The last thing to go is usually a report one customer's finance team has used for years. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a stock system that means a few days with the office, the floor and the code, finding how the scanners talk to it, where each customer's rules live and which reports the customers open, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a warehouse stock system takeover What the assessment establishes for a stock system, and why each item matters: | Check | Why it matters | |---|---| | Is there source for the WinForms program and the SSRS report definitions, and do they match what runs? | A WinForms program without source can be kept running or replaced, and little in between. Where the developer moved on, the source is often on a drive nobody has opened since. | | How do the scanners talk to it? | A terminal session, a web service or a direct database connection each lead to a different scanner stage. The answer sets the price of the new handheld app. | | Which SQL Server and SSRS versions, and where do the report subscriptions run? | SQL Server 2016 lost its updates in July 2026. The subscriptions are the customers' contract with the business and move first. | | Which customer rules live in code, which in the customer table, and which in the spreadsheet? | A rule in code is a developer change; a rule in data is a screen. The mix decides how much of the storage invoice can move into the system. | | How does each customer send orders, and who re-keys them? | Email, CSV, a web shop, a marketplace or nothing at all. Each is a feed to keep or replace, and the re-keying is the measure of what the login saves. | | How is the storage count produced, and can last month's be re-run? | If the count cannot be reproduced, disputes cannot be settled from the system. The log is the evidence. | | How are batch, best-before and hold status stored, and does the nightly report show them? | The customers' picking and quality rules depend on these fields. Where they are free text, the modernised screens need them structured first. | | Which reports do the customers receive, and which do they open? | Every SSRS report is a promise. Those nobody opens are retired; those a finance team runs on are rebuilt first and checked against the old output. | ## Questions Q: Can the customers see their own stock without us emailing reports? A: Yes, on the same data the office uses. A login shows each customer their own stock, on hold and available, and lets them key orders, and the nightly report keeps going for those who prefer it. It is built beside the existing program, so nothing about the floor changes. Q: We cannot get the scanners any more. Does that mean a new WMS? A: No. The scanners talk to the system in one of a few ways, and the assessment finds which. A new handheld app against the same database is usually a stage on its own, run beside the old devices until the last one dies, rather than a reason to replace the system. Q: Every customer has different rules. Will they survive? A: They are the point. Each customer's picking, hold and storage rules are found in the code, the tables and the spreadsheet, written down with the office, and put into data the office can see and change. A rewrite from scratch is where rules like these get lost, which is why the old program stays. Q: Can the nightly report keep going while this happens? A: Yes. The report subscriptions are the first thing protected, kept running on a reporting server that is still supported before anything else changes, and checked against the old output. The customers should not notice. --- # Systems that run manufacturing and engineering businesses URL: https://www.solvewithsoftware.com/systems/manufacturing-engineering Title: Manufacturing Systems We Modernise Description: The systems that run small manufacturers, old and new, MRP to shop-floor booking, and where AI helps on each. From £395 + VAT. Last reviewed: 2026-09-14 Small manufacturers and engineering firms run on systems that started as a database for one job and became the factory. Solve With Software takes those systems over and modernises them in stages, so the office keeps the screens it knows while the shop floor, the stores and the customers get live information, and AI reads the supplier paperwork and enquiry packs that someone types in today. The pages below describe the kinds of system we see, in both their generations, and what modernising each brings. ## Where these systems run Machine shops, fabricators and assemblers across the UK run on systems like these, from the Midlands and the North to the estates around Ipswich, Colchester, Braintree and Bury St Edmunds nearer home. Most make to order for a handful of larger customers who audit them every year, and the system at the centre usually began in Microsoft Access or Excel and has been extended by the same one or two people ever since. Colchester is our base, and the factory can be anywhere in the UK. The work is done remotely, with on-site visits across Essex, Suffolk and London when the system needs them; the regional page (https://www.solvewithsoftware.com/essex-suffolk-london) covers the local side. ## Old Guard or New Legacy: two ways the same factory system was built **The Old Guard** started between the early 2000s and about 2013, often as a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database the production manager or the quality manager built, sometimes with a Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) or Delphi (https://www.solvewithsoftware.com/modernise/delphi) program on the shop-floor terminals and an Excel workbook for the quotes. The homegrown MRP (https://www.solvewithsoftware.com/systems/manufacturing-engineering/homegrown-mrp-system) and the quality and traceability system (https://www.solvewithsoftware.com/systems/manufacturing-engineering/quality-traceability-system) usually began this way, and the terminals by the machines (https://www.solvewithsoftware.com/systems/manufacturing-engineering/shop-floor-data-capture-system) have run the same program since. **The New Legacy** is the same system built from about 2016 by a freelancer or a small agency as a browser system with a tablet app, or in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or Zoho Creator by an engineer who wanted rid of the workbook. Since 2023 some have been attempted in an AI builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) halfway. Newer, and just as hard to change. Many manufacturers this size keep the accounts, and sometimes the stock, in a bought package, with the homegrown system beside it for the BOMs, the works orders or the quotes (https://www.solvewithsoftware.com/systems/manufacturing-engineering/job-shop-quoting-system). The join between the two is usually where the work starts. ## What modernising them usually brings The shop floor gets a screen: the works order on a tablet at the machine, time booked where the work happens, job status the office can see without walking round. The stores get barcodes and a stock figure that is right. The auditor gets traceability on one record instead of three. And the whole thing comes off the one Access file, onto a supported database with a real backup, while the office screens keep working until each is replaced. Once the system is safe to change, AI takes the retyping off the desk as well: the supplier acknowledgement read onto the purchase order, the enquiry pack drafted into a quote, the mill certificate read in at goods-in. It can also answer the questions the reports never covered, such as which works orders are waiting on a late delivery. Each system page works out the time that gives back at its own volumes. ## Questions Q: Does the factory have to stop while the system is modernised? A: No. The old system keeps running and stays the fallback, and each new piece is added beside it: a booking screen on two machines first, the stores scanning into the same stock records the office screens read. A screen is retired when nobody opens it any more, and not before. Q: Our BOMs, rates and booking rules are twenty years of decisions. Do they survive? A: They are the reason to modernise rather than replace. The assessment reads them out of the database, the forms and the spreadsheets beside them, and writes them down with the people who use them, so they go into the new pieces as they are. The history moves with the data, revisions and all. Q: Our biggest customer audits us every year. Will modernising get in the way of it? A: The first stage changes nothing the auditor sees. The data goes onto a supported database with a tested backup, the screens and the certificates carry on as they are, and the visible changes are paced around the audit dates. Traceability on one record usually comes later, and it is the stage that makes the next audit shorter. Q: Is AI any use on a system like ours, or is that for bigger manufacturers? A: It is useful at this size, in the paperwork around the system rather than in the planning or the BOMs. It reads what already arrives in writing, the supplier acknowledgement, the customer's schedule, the enquiry pack, the mill certificate, and drafts the entry for someone to check rather than type, or flags a booking or a quote that does not match what the floor did last time. For the buyer and the estimator, that is most of the typing they do before the real work starts. It comes after the first stage, once the system is safe to change, and the assessment maps where it would pay back on the system as it stands. Q: What does it cost, and how soon does something work? A: The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit, and produces a report with costed options and a fixed price for each. The first stage is sized so something is working in about six weeks. The report is yours. Take it to us, another developer, or nobody. --- # The homegrown MRP system that runs your factory URL: https://www.solvewithsoftware.com/systems/manufacturing-engineering/homegrown-mrp-system Title: Homegrown MRP System Modernisation Description: A manufacturer's own MRP: BOMs, works orders, stock and purchasing, what modernising brings and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A homegrown MRP system is the factory's memory: how every product is made, what is in stock, what is on order, and what has to be bought to build next week's works orders. Solve With Software takes over MRP systems that grew inside a manufacturer over years, keeps them running, and modernises them in stages, so the office keeps the screens it knows while the shop floor, the stores and the customers get live information. AI helps first with the supplier acknowledgements the buyer retypes onto purchase orders, and the assessment prices each stage before you commit. The Old Guard: Begun between 2003 and 2012 in Microsoft Access by the production manager or a contractor, on the office server beside the Sage accounts. The New Legacy: Built between 2016 and 2022 by a freelancer or small agency in PHP or .NET Core, or on Zoho Creator, with a goods-in tablet and a shortages dashboard. Where AI helps: Supplier acknowledgements drafted onto the purchase order: 200 to 600 lines a month at a minute a line comes to about one to two hours a week. ## What a homegrown MRP system does It started as a bill of materials database. Then it became the factory. A typical business running one of these has 30 to 120 staff on one site, makes to order in batches, carries somewhere between 500 and 5,000 live part numbers, keeps 50 to 200 works orders open at once, and has a buyer placing 200 to 600 purchase order lines a month. It does the same job whether it was started in 2005 or built in 2018. Day to day it explodes a sales order into the parts and operations needed to make it, raises the works orders with the right drawing revision, tells the buyer what to order and when, prints the job cards and the route cards, books stock in and out, and produces the despatch note with the certificate of conformity behind it. It is rarely alone. In many of these factories the accounts, and sometimes stock and purchasing, run in Sage 200 or a similar bought package, and the homegrown MRP sits beside it for the BOMs, the works orders and the route cards. Which of the two holds the stock figure everyone trusts differs from building to building. The rules it holds are the ones no package would know: - A BOM revision applies from a given works order number, and old stock is used up first unless the customer's drawing says otherwise. - Each operation carries a scrap allowance, set years ago from what happened on the machine. - Three customers use their own part numbers, and the system translates both ways. - A works order cannot close until inspection has signed it, except for the product family that is inspected at despatch. - The supplier lead times in the system are the buyer's memory, corrected by hand every time a delivery is late. ## The Old Guard: the Access database that became the factory Started somewhere between 2003 and 2012 as a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database, written by the production manager who was good with computers or by a contractor brought in for a few months, to hold the BOMs. Works orders followed, then stock, purchasing and despatch. The data may have moved to SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) along the way or may still be an Access file on the office server, with a Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) helper program for the labels or the barcode wand, Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports) for the job cards and the route cards, and a month-end export to Sage (https://www.solvewithsoftware.com/modernise/sage-integrations). The front end is copied to each PC in the office, and the back end lives on the server that came with the building. The person who built it has other jobs to do, or has retired, and the last change was made with everyone out while the file compacted. Nobody has tried restoring the backup. It cannot be seen from the shop floor, so the time booking is on paper and the job status is a walk round the factory. ## The New Legacy: the MRP a freelancer built around 2018 The same system built between 2016 and 2022, usually by a freelancer the accountant recommended or by a small agency, as a web system in PHP (https://www.solvewithsoftware.com/modernise/php) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), or put together on Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) by the production manager who followed the one with the Access database. It opens in a browser, the stores have a tablet for goods-in, the MD has a dashboard with the shortages on it, and the biggest customer can log in to see where their order is. From the office it looked like the ERP question had been answered. What stops it is the stock. The Sage link was written for the version the accounts ran then, and when the accounts moved up a version the two stock figures began to drift, so the stores keep a count sheet again. A fix to the purchasing screen broke the export outright and was taken back out. The freelancer has a full-time job now, and nothing underneath has been updated since it went live. Since 2023 a few production managers have tried again with an AI app builder, got BOMs on screen quickly, and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at stock allocation, where the rules stop being simple. Whichever version the factory runs, month end now means the stores and the accountant agreeing a stock figure over a printout, with the dashboard left out of it. ## What does it give the business? **A factory that knows what to make, what to buy and what it has, from one screen.** It is the reason the business never bought an ERP package. A package would need configuring to fit how the factory works; this system already fits, because it was written from how the factory works. A sales order becomes purchase requirements in seconds, and the buyer sees the shortages for next week before Monday. Every works order goes out with the right revision of the drawing, which is why the returns are as rare as they are. Stock counts reconcile, because the system has booked every issue since 2005. When a customer asks for the certificate of conformity from a batch shipped three years ago, the stores find it in a minute. And at month end the figures go to Sage in one export, so the accounts and the factory agree. ## What it stops doing as the factory grows Systems like this hold the factory together. What they stop doing is growing with it. **The Access ceiling.** An Access file has a size limit and a limited appetite for several users at once. Somewhere past ten people the system slows, then it corrupts, and the office learns the phrase "everyone out while we compact it". The nightly backup is a copy of the file, and nobody has tried restoring it. **Only one person can change it.** The person who built it is the production manager with other jobs to do, has retired, or is the freelancer who now answers in weeks. Whichever generation it is, changes queue behind production. The workaround for the workaround is a spreadsheet next to the system, and there are now several. **It cannot see the shop floor.** Time booking is on paper or in a separate spreadsheet, job status is a walk round the factory, and the customer asking where their order is gets a phone call back that afternoon. The newer version has a dashboard, and the dashboard is fed from the same paper. The auditor asking for traceability gets three sources that mostly agree. **The platform is aging under it.** Windows 10 support ended in October 2025, and the PCs by the machines are still on it. If the data moved to SQL Server 2016, its updates ended in July 2026. Neither stops the system today. Both make the Cyber Essentials renewal and the customer supplier audit harder each year. ## What does modernising it bring? **The same BOMs and works orders, on the shop floor and in the stores, live.** Each of these builds on something the system already does well. **Works orders on the machine.** The job card on a tablet by the machine, with the drawing revision and the operations, and a tick per operation as it is done. The office sees where every job is without leaving the desk. **Time booked where the work happens.** The operator books on and off the job at the machine, and the actual time goes against the estimate. The scrap allowances stop being folklore and start being measured. **Stock that is right.** Barcodes at goods-in, at issue and at despatch, writing to the same stock records. The stores stop counting to find out and start counting to confirm. **Purchasing from real lead times.** Every delivery updates the supplier's lead time, so the buyer's memory is in the system and survives the buyer's holiday. **Traceability the auditor can follow.** Batch, certificate, operator, machine and inspection on one record, reachable from the despatch note. The three sources become one. **Off the Access file.** The data comes off the Access file onto a supported database, on a supported server, with backups that have been restored on purpose. Several users at once stops being a risk. The Access screens keep working against the new database until each one is replaced. The old system is not switched off for any of this. Each piece is added beside it. ## Where could AI earn its keep in an MRP system? **In the acknowledgements the buyer retypes, and in the questions about late parts that no report in the system answers.** The BOMs and the planning stay with the people who know the factory. AI works on the records and paperwork around them: **Supplier acknowledgements, read onto the order.** The acknowledgement arrives as a PDF with a new date on two lines and a price change on a third, and the buyer types the changes in. AI reads it, drafts the update and shows the buyer what moved. At 200 to 600 order lines a month and a minute or so a line to check the acknowledgement and type the change, that comes to about three to ten hours a month, roughly one to two hours a week for the buyer. **Which jobs is this late delivery holding up?** The shortages report lists parts, not which works orders wait on which late purchase order, so the buyer works the chain out by hand before the production meeting. Asked in plain words, AI answers from the allocations and due dates on read-only access, and lists the orders behind the answer so the buyer can check them. With 50 to 200 works orders open, the chain takes most of an hour to trace by hand before each production meeting and a few minutes to check, so one meeting a week works out at most of an hour back. **Stock bookings that do not fit.** An issue ten times the BOM quantity, a receipt against a superseded revision. AI flags them the day they are booked, so the stores correct a short list each morning. Left to the count, they take a day or two of hunting before each stocktake, which at a stocktake a quarter adds up to four to eight days a year. Not worth doing: replacing the BOM editor with a chat window. Engineers want a grid, and a model that guesses at a BOM line is a scrap batch waiting to happen. A draft purchase order change needs somewhere safe to land, and an Access file that corrupts under load is not that place, so AI follows the move off the file. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where it would pay back on the system as it stands. ## How the takeover runs The first move is the one that removes the risk of losing everything. 1. **Split and stabilise.** The data comes off the Access file onto a supported database and the Access screens are pointed at it. Corruption stops, several users at once becomes normal, and there is a real backup. This goes first because a modernisation that starts on a file that could corrupt tomorrow is built on sand. 2. **Shop-floor time booking.** The first new piece is the one the office has never had: a screen on a tablet at each machine, booking time against the works order in the same database. Small, and live in weeks. 3. **Stores and goods-in.** Barcoded receipts, issues and despatch, writing to the stock records the Access screens still read. 4. **The office screens, one at a time.** Works orders, purchasing, then the BOM editor, each opened in a browser and run beside its Access form until the office chooses the new one. 5. **Retire Access** when nothing still opens it. The BOM editor is usually the last thing to go, because the engineers trust it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an MRP system that means a few days with the office, the stores and the database, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a homegrown MRP takeover What the assessment establishes for an MRP system, and why each item matters: | Check | Why it matters | |---|---| | Is the database split into a front end and a back end, and how big is the back-end file? | An unsplit Access file shared by ten people is the commonest cause of corruption. Its size says how close the ceiling is. | | Are the forms, queries and VBA all inside the Access file, or is there a separate program too? | Access usually carries its own source, which is good news. A VB6 helper program or a compiled add-in may not. | | How are BOM revisions handled, and what happens to open works orders when a revision changes? | This is the rule a new screen is most likely to get wrong, and the most expensive to get wrong on the floor. | | Where is time booked, and does it reach the system? | If it is on paper, the first modernisation stage is already chosen. | | Which records live in Sage and which in the MRP, and which one is the master for stock? | Where purchasing or stock sits in the package and the BOMs in the MRP, both hold a stock figure and they drift. The answer, the export and the month-end corrections around it are the specification for the accounts link. | | Which reports does the business run on? | Crystal and Access reports carry costing rules of their own. The works order print is a specification. | | What are the PCs by the machines running, and what else is on them? | Windows 10 support ended in October 2025. The shop-floor stage depends on what those machines can run. | | Which fields does the auditor ask for, and where do they live? | Traceability is usually spread across the system, a spreadsheet and a filing cabinet. The stage that joins them is the one the audit pays for. | ## Questions Q: Should we just buy an ERP package instead? A: Sometimes, and the assessment says so when that is the answer. The question is what a package would have to be configured to do, and the answer is usually a list of the rules your system already holds. Where Sage or another package already runs the accounts, the stock or the purchasing, the assessment also settles which system is the master for each record before anything moves. Modernising the parts that matter and keeping the rest is often cheaper than a package and the year of fitting it. Q: Our whole MRP is one Access file. Can it be modernised or does it have to be rewritten? A: Modernised. The data comes off the Access file onto a supported database first, and the Access screens keep working against it, which takes away the corruption and the user limit on day one. From there each screen is replaced when there is a reason to, and never all at once. Q: Will we lose our BOM history? A: No. The history is the most valuable thing in the system and the reason to modernise rather than replace. It moves with the data, revisions and all, and the new screens read the same records the old ones did. Q: Can the shop floor use it on tablets? A: Yes, and that is usually the first new piece, because the office has never had live job status and the operators are already used to a phone. A screen on a tablet by the machine, booking against the same works orders, is a small stage that proves the rest. Q: How long before something is live? A: The first stage is sized so something is working in about six weeks. For an MRP system that is usually the move off the Access file, which the office notices only as the crashes stopping, or the shop-floor booking screen, which everyone notices. --- # The quoting and works order system that runs your job shop URL: https://www.solvewithsoftware.com/systems/manufacturing-engineering/job-shop-quoting-system Title: Job Shop Quoting System Modernisation Description: A job shop's quoting and works order system: estimating, job cards, job costing, what modernising brings and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A job shop quoting system is where a drawing becomes a price, and where the winning price becomes a works order, a job card and a cost when the part ships. Solve With Software takes over quoting and works order systems that grew inside a subcontract machine shop or fabricator, keeps them running, and modernises them in stages, so the estimator keeps the screen they know while the shop gets one record from the enquiry to the invoice. AI helps first with the enquiry pack, reading the customer's drawings and part list into draft quote lines for the estimator to check, and the assessment prices each stage before you commit. The Old Guard: An Excel quoting workbook from around 2005 and an Access or .NET Framework works order program from about 2013, on the office PCs and server. The New Legacy: Quoting in a browser, built between 2016 and 2022 by an agency or freelancer in PHP or .NET Core with an Ionic tablet app, or on Power Apps. Where AI helps: Enquiry packs drafted into quote lines: 40 quotes a week at five to ten minutes each works out to about three to seven hours a week. ## What a job shop quoting system does day to day One drawing, one estimator, and a price by four o'clock. A typical business running one of these has 15 to 60 staff in one unit on an industrial estate, machines or fabricates to other people's drawings, and sends out somewhere between 20 and 80 quotes a week. Whether the quoting lives in a workbook started in 2005 or on a browser screen built in 2019, the job is the same. In the estimator's words, it takes the drawing and the enquiry, builds the quote a line at a time (material at the last price paid, each operation with a setup and a run time, plating or heat treatment at the subcontractor's price, a margin on top) and prints it with the quantity breaks across the bottom. When the order arrives, the quote becomes a works order, the job card prints with the route on it, operators book time against it, and the job is costed when it ships, quoted against actual. It knows what was quoted. It does not know what was lost, or why. The rules it holds are the ones a new estimator gets wrong: - Setup is charged once per batch, but if the same part is ordered again within six months the second setup is quoted at half. - Material is quoted at the last price paid plus a percentage, except for the two customers who supply their own. - Every machine has its own hourly rate, and three customers have a negotiated rate that overrides all of them. - A repeat job takes its route and times from the last works order, unless the drawing revision has changed. - The quantity breaks are always 1, 5, 10 and 50 off, because that is what the biggest customer asks for. Almost none of that is written down anywhere else. ## The Old Guard: Quote Calc v7 and a works order program The quoting started as an Excel (https://www.solvewithsoftware.com/modernise/excel-to-system) workbook, built around 2005 by the owner or the first estimator, with the hourly rates, the material prices and the margin in cells on the last sheet. Works orders came later: a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database for the job card, the route and the time bookings, or a small .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) Windows program a contractor wrote around 2013 to take over the Access forms. The workbook lives on the estimator's PC, the program is installed on each office PC from a folder on the server, and the Access data sits on a server that was in the unit when the shop moved in. The contractor has moved on, and the zip of source left on the server may or may not match what runs. The workbook's formulas make sense to one estimator. The quote number is still typed into both, and the program has gone years without a change, because nobody left in the unit knows which screen feeds which table. ## The New Legacy: estimating in a browser, around 2019 The same quoting and works orders built between 2016 and 2022, usually by a small agency or a freelancer as a web system in PHP (https://www.solvewithsoftware.com/modernise/php) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), or put together on Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by the estimator who followed the one with the workbook. The estimator prices a drawing in a browser, the accepted quote raises the works order with a button, the operators book time on a tablet by the machine through an Ionic (https://www.solvewithsoftware.com/modernise/ionic) app, and the owner has a margin page. From the office it looked as though the workbook had finally gone. The trouble starts at the quantity breaks. They were built as four fixed columns, 1, 5, 10 and 50 off, so a customer who asks for 25 off gets a second quote typed by hand, and the one attempt at a fifth column stopped the lead times printing. The agency has since been bought by a larger firm with no appetite for work this size, and the tablet app will not install on a new tablet. From 2023 some estimators tried again with an AI app builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) where a won quote has to become a works order. ## Why does the business still run on it? **A quote out the same day, and a job that is costed when it ships.** The quoting side is why one estimator can price forty enquiries a week and still walk the floor. Rates, material and margin are already in it, so a quote for a bracket nobody has made before takes twenty minutes and a repeat takes five. Two estimators quoting the same drawing get the same number. The works order side turns a price into a job the shop can run. The job card goes to the floor with the route on it, the time comes back against it, and when the job ships the owner can see whether the quote was right. Over a few years that becomes the shop's best asset: a history of what every part took, on which machine, by whom. ## Where it starts to slow the shop down Nothing in a system like this breaks. The gaps around it widen. **The quote and the job live in two places.** The estimator quotes in the workbook and the office retypes the winning ones into the works order system. When the drawing revision changes between the two, the job card carries the old one, and the shop finds out at inspection. **The rates are whatever was last typed in.** In either generation, hourly rates and material prices sit in cells or on a settings screen nobody reviews, and the margin has not moved since it was set. Material-heavy jobs go out under-priced and the small ones carry them, and the year-end accounts are the first place anyone sees it. **The program is where the contractor left it.** The server under the works order program runs Windows Server 2012, which ended in October 2023. Whoever patches the server leaves the program well alone, and the customer's supplier questionnaire now asks about both. **The big customers want it in their portal.** Enquiries arrive through a supplier portal with a deadline on them, and the quote has to go back the same way, a price and a lead time per line and per quantity break. The system makes a PDF, so the estimator types every number twice. ## What changes once the quote and the job share a record? **One record from the enquiry to the invoice, with rates the owner can see.** Each of these builds on something the quoting and works order side already does. **The quote becomes the works order.** The estimator's screen writes into the same database the job card prints from, so the drawing revision, the route and the times on the quote are the ones the shop makes to. Nothing is retyped. **Rates with a date on them.** Hourly rates, material prices and the margin on a screen the owner owns, each showing when it last changed, with the material price offered from the last price paid. **Margin by customer, without waiting for year end.** The job costing the system already does per job, rolled up by customer, by part and by machine, on a page the owner reads on a Friday. The next quote to that customer starts from what the last ten jobs cost, on purpose rather than from memory. **Won, lost, and why.** Every quote gets an outcome and a reason, so the hit rate by customer and by part type is a number rather than a feeling. **Quotes the portal accepts.** The same quote produced as the PDF on the letterhead and as the file the customer's portal takes, price and lead time per line and per quantity break, from one screen. The workbook, or the old quote screen, stays open through all of this. The new pieces are added beside it, and the estimator closes it when the new screen is better. ## Where does AI give the estimator time back? **In the enquiry packs keyed in by hand, and in the times nobody checks against the last job.** AI reads and checks here, and the pricing stays with the estimator: **The enquiry pack, read into the quote.** The enquiry arrives as an email with the drawings and the customer's spreadsheet of part numbers, revisions and quantities, and the estimator keys a line per part before pricing anything. AI reads the pack and drafts the header and the lines for the estimator to check, so the time goes on the operations. For a shop sending 40 quotes a week, at five to ten minutes of keying a pack, that works out to 200 to 400 minutes, about three to seven hours a week for the estimator. **Times checked against what the floor booked.** Before a quote goes out, AI sets its setup and run times beside the actuals on the last few jobs for the same part and flags the lines well outside them. Repeat parts make up much of a job shop's quoting, and each meant pulling old job cards. If 20 of those 40 quotes a week are repeats, at three to six minutes a look, the estimator's saving adds up to one to two hours a week, and drifted times get caught on the way. **Subcontract prices read from the reply.** The plater's or heat treater's price comes back as an email or a PDF and gets typed onto the operation line. AI reads the price and the lead time onto the line for the estimator to confirm. With 20 to 80 quotes a week and an outside process on one in two, at a couple of minutes a reply, that comes to 20 to 80 minutes a week for whoever chases them. Not worth doing: pricing a new part from the drawing alone. An estimator who has stood at the machine beats any model on a part nobody has made before. A drafted quote line needs a quote record to land in, and a workbook on one PC is not one, so this waits for the quoting screen and the stable program under it. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where it would pay back on the quoting as it stands. ## Where the work starts, and why Stabilise the program first, then give the estimator one screen, then everything else. 1. **Stabilise.** The source for the works order program found, or recovered from the running program where the zip does not match, the data moved off the Windows Server 2012 machine onto a supported database, and a test copy so a change can be tried without touching the job cards. This goes first because until it is done, nothing about the program can be changed safely. 2. **The quoting screen.** The first new piece is the one the estimator feels: the workbook's logic on a screen in a browser that writes the quote into the same database the works orders come from. The workbook stays open beside it, and for a few weeks both produce the same number, which is the test. 3. **Rates, outcomes and the portal file.** The rate table with dates, won and lost on every quote, and the portal upload. Each a stage on its own, each priced on its own. 4. **Margin by customer and the enquiry reader.** The costing roll-up and the AI that reads the enquiry pack, once there are enough quotes in one place to read against. 5. **Retire the workbook and the old program** when nothing is typed into either. The last thing to go is usually the quote print on the letterhead, because the owner likes how it looks. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a quoting system that means a few days with the estimator, the workbook and the works order program, finding where the rates and the rules live and what the portal customers need, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a job shop quoting system takeover What the assessment establishes for a quoting and works order system, and why each item matters: | Check | Why it matters | |---|---| | Does the workbook's costing match what the works order program does with a quote once it is typed in? | Two systems that agree by habit rather than by design are the first thing to reconcile, and the place the drawing revision goes wrong. | | Where do the rates live, in cells, in a table or in code, and who last changed them? | Rates in cells are a specification nobody has read for years. Rates in code are a developer change every time material goes up. | | Is there source for the works order program, and does it build? | A .NET Framework program without matching source can still be read, but the options narrow. Which framework version it targets says what it will run on. | | Where does the Access data sit, and what is that server running? | An Access file shared across the office from a Windows Server 2012 machine, out of support since October 2023, sets the first stage. | | How is a repeat job found: by part number, by drawing number, or by the last works order? | The history is the shop's most valuable data, and the way it is keyed decides whether a modernised quote can find it. | | Which customers require which quote format, and which come through a portal? | The portal file is a specification, and its deadline is the reason the estimator types things twice. | | When does a job's actual cost exist: at despatch, at month end, or when someone types the cards in? | The lag between the job shipping and the owner knowing its margin is what the costing roll-up removes, and it sets which stage that is. | | What raises the invoice, and does the works order close it? | The invoice link is where a quoting system meets the accounts, and its exceptions are rules to keep. | ## Questions Q: Can the estimator keep quoting in Excel? A: Yes, for as long as it is the better tool. The new quoting screen is built from the workbook's logic and writes to the same database as the works orders, and for a while both are used and compared. The workbook closes when the estimator stops opening it, and not before. Q: Our rates and margins are in the spreadsheet. Do they survive? A: They are the first thing found and the last thing changed. They come out of the cells, get written down with the estimator, and go into a table with a date against each one, where the owner can see and change them. The numbers stay as they are until you decide otherwise. Q: We don't have the source code for the works order program. Is that the end of it? A: No. A .NET Framework program can usually be read well enough to recover what it does, and where it cannot, the database and the screens say most of it. The assessment establishes which. Support for the program continues either way while the new pieces are built. Q: Will it produce what a customer portal wants? A: Usually. The format is set by the customer and documented, and the assessment collects the formats the shop has to meet and prices the stage that produces them. Until then the PDF keeps going out as it does now. Q: How soon does something work? A: The first stage is sized so something is working in about six weeks. For a quoting system that is usually the quoting screen beside the workbook, producing the same number from the same rates. --- # The quality system your accreditation audit runs on URL: https://www.solvewithsoftware.com/systems/manufacturing-engineering/quality-traceability-system Title: Quality and Traceability Modernisation Description: Batch traceability, certificates of conformity, NCRs and calibration: what modernising brings and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A quality and traceability system follows a heat number from goods-in to the despatch, prints the certificate of conformity in each customer's wording, holds the non-conformance reports and keeps the calibration register, and it is the system the accreditation audit is run on. Solve With Software takes over quality systems that a quality manager built in Access years ago, keeps them running, and modernises them in stages, so the certificates keep printing while the trail, the gauges and the non-conformances come onto one record. AI helps first at goods-in, reading each mill certificate into the batch record for the inspector to confirm, and the assessment prices each stage before you commit. The Old Guard: Written around 2010 by the quality manager in Microsoft Access, with SSRS certificates on a report server and the calibration register in Excel. The New Legacy: A certificate portal built between 2016 and 2022 by a freelancer or agency in PHP or .NET Core, or on Zoho Creator or Power Apps. Where AI helps: Mill certificates read into the batch record: 20 to 60 deliveries a week at five minutes each comes to about one and a half to five hours a week. ## Inside a quality and traceability system Every part that leaves has a certificate behind it, and this is where it comes from. A typical business running one of these has 25 to 100 staff on one site, a quality manager and one or two inspectors, books in 20 to 60 deliveries of material a week, and sends out 50 to 200 despatches a week, each with a certificate of conformity. It holds ISO 9001, often with a customer-driven accreditation on top, AS9100 for aerospace or ISO 13485 for medical work, and the whole system is built around the annual audit. Whether the batches sit in an Access database from 2010 or a browser system from 2018, the job is the same. In the quality manager's words, the material certificate is scanned at goods-in and tied to the heat number, which follows the batch through the shop. At despatch the certificate prints: the material, the processes and the subcontractors' certificates, the inspection results, in each customer's wording. A non-conformance, raised at inspection or from a return, carries its disposition, root cause and corrective action until it is closed. The calibration register lists every gauge with its interval and next due date. The rules it holds are the ones the auditor asks about: - Each customer has its own certificate wording: one wants the heat number and specification, another the mill certificates attached, the aerospace one the first article reference. - A concession needs the customer's written agreement, and its reference goes on the certificate for that batch. - A gauge found out of tolerance shortens its own interval and triggers a search for every batch it measured. - A split batch keeps both halves linked to the parent's certificates. - A third non-conformance against one supplier in a year raises a corrective action request. Most of that is in the quality manual. The rest is in the system. ## The Old Guard: the quality manager's Access database Written around 2010 by the quality manager in Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) to hold the batch numbers and the certificates, and grown since to take the non-conformance reports. The calibration register stayed in an Excel (https://www.solvewithsoftware.com/modernise/excel-to-system) workbook that was always going to be moved in and never was. Where the data reached SQL Server, the certificate and the audit reports became SSRS (https://www.solvewithsoftware.com/modernise/ssrs) reports on a report server in the corner, written by someone who has since left. The Access front end sits on the quality office PCs and the data on the server in the comms cupboard. The quality manager who wrote it now runs the audits and has no time to change it, or has moved on. The report definitions are opened rarely and nervously, and every new customer's wording joins a queue behind the one person prepared to try. ## The New Legacy: a certificate portal from around 2018 The same trail built between 2016 and 2022, usually by a freelancer or a small agency as a web system in PHP (https://www.solvewithsoftware.com/modernise/php) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), or put together in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by the quality manager who followed the one with the Access database. Inspectors enter results on a tablet at the bench, the certificate goes out as a PDF with the despatch email, and the bigger customers download their own certificates from a login. From the quality office it looked as though audit week had been solved. The certificates are what hold it still. Each customer's wording was written into the template code, so a new customer means a developer, and the last one added took the heat number off a different customer's certificate, which that customer's goods-in noticed before the quality office did. The templates have been frozen ever since. Behind that, the freelancer is in a permanent job and the framework underneath has not had an update in years. Since 2023 a few quality managers have tried again with an AI app builder, got batches and certificates on screen, and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the calibration register, where a gauge recall has to reach back through every batch it measured. ## What does it do for the audit? **An answer for any batch the auditor points at, in the time it takes to type the number.** The audit is the reason it exists. The auditor picks a despatch from six months ago, and the screen shows the batch, the material certificate behind it, the plating certificate from the subcontractor, who inspected it and against what. That trail, on demand, is the difference between a morning's audit and a week of finding paper. It does the same for the customer who sends a part back. The batch number on the returned part opens its history, the non-conformance is raised against it, and the reply goes out with facts rather than an apology. The certificate of conformity on every despatch, in the customer's wording, is why the aerospace and the medical work is there at all; without it the parts are not accepted at the customer's goods-in. The calibration list keeps the gauges in date, and the management review has the non-conformance trend on one sheet. ## Where the trail starts to break Systems like this pass the audit every year. What they cannot do is grow the way the customers' audits have. **The register never joined the database.** Calibration lives in the workbook, the certificates in Access, the mill certificates as PDFs in a folder named by year, and the trail across the three is the quality manager's memory. When the quality manager is on holiday, the audit is moved. **The report server has a date on it.** The certificate and the audit reports are SSRS reports on a report server running Windows Server 2016, which ends in January 2027, and the person who wrote the report definitions has left. The office has learned not to touch it. **A new certificate wording means Word.** In either generation each customer's wording is built into the report or the template code itself, so when a new customer asks for a different certificate the quality manager makes it in Word, prints it, and files a copy by hand. There are now several of those, and the auditor has noticed. **Non-conformances are raised and not chased.** The form is easy to raise and has no owner, no due date and no reminder, so the management review shows reports open since 2023 with nobody assigned. The customer's supplier audit now asks for closure times, and the system cannot say. ## What does modernising it add? **One trail from the mill certificate to the despatch, with the gauges and the non-conformances on it.** Each of these extends something the system already keeps. **Calibration in the same record as the batch.** The register becomes a screen in the database, and the inspector records which gauge measured which batch. A gauge found out of tolerance recalls every batch it touched in one query, which today is a week with the workbook and the job cards. **The certificate as data, worded per customer.** The customer's wording held as a template the quality manager edits, and the batch's facts poured into it at despatch. The heat-number version, the mill-certificate version and the first-article version all come from one screen, and the Word copies stop. **Non-conformances with an owner and a clock.** Every report has a person, a due date and a reminder, and the management review shows age and closure time. The supplier audit's closure question gets a number. **The audit pack on a page.** The batch trail, the calibration status, the open non-conformances and the supplier record as pages the quality manager opens, and a read-only login the auditor can be given for the day, in place of reports on a server with a date on it. **The mill certificates where the batch is.** The PDFs captured at goods-in against the heat number, so the folder named by year becomes a link on the batch record. The existing forms and reports keep running through all of this. The new pieces are added beside them, and each is retired when nothing prints from it. ## Which paperwork could AI read for the quality office? **The certificates that arrive as PDFs and scans, read and checked for a person to confirm, and the heat-number questions no report answers.** The paperwork arrives from outside and gets typed in, and the questions mean searching three places. AI pays back there, and the decisions stay with people: **Mill certificates read at goods-in.** The material certificate arrives with the delivery as a PDF or a scan, and the inspector types the heat number, the specification and the test results against the batch. AI reads the certificate into the record and flags any result outside the specification, and the inspector confirms rather than types. At 20 to 60 deliveries a week and five minutes or so of typing each, that works out to about one and a half to five hours a week for the inspector. **Subcontractor certificates checked against the order.** The plating or heat treatment certificate comes back with the parts, and somebody checks the process, the specification and the quantity against the purchase order before filing it. AI checks each against the order and shows only the mismatches. If half of 50 to 200 despatches a week have an outside process behind them, at two minutes a certificate the check comes to 50 to 200 minutes, from under an hour to over three hours a week, and shrinks to minutes. **"Which despatches went out on that heat?"** A customer or the auditor asks which despatches carried one heat of material, and whether any were on concession. No report covers it, so the quality manager searches the database, the folder and the Word copies. AI answers in plain words from the batch records, which it reads and cannot amend, and lists every despatch and certificate behind the answer for checking. At 40 to 50 minutes of searching a question and two dozen or so in audit week, that adds up to about 16 to 20 hours. Not worth doing: letting a model decide a concession. The customer decides that, in writing, and the system's job is to hold the letter. Nothing should write into a batch record before it has a tested restore and a test copy, so this comes after the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where it would pay back. ## The stages, and which goes first The audit date does not move, so nothing here can stop the certificate printing. 1. **Stabilise.** The data on a supported database if it is not on one already, the report definitions recovered from the server and kept somewhere that is backed up, a restore that has been tried, and a test copy where a certificate can be printed without a despatch behind it. This goes first because the January 2027 date on the report server is the one deadline in this system that is not the auditor's. 2. **Calibration into the database.** The first new piece is the workbook: the register as a screen in the same database, with the gauge recorded against the inspection from the day it goes live. Small, and the recall query exists for the first time. 3. **The certificate as data.** Templates per customer, the batch's facts filled in at despatch, run beside the SSRS report until the quality manager stops opening it. The Word certificates go first. 4. **Non-conformances, the audit pages, the mill certificates.** Each a stage, each priced on its own, and the AI reading at goods-in once the certificates are being captured. 5. **Retire Access and the report server** when nothing prints from either. The last thing to go is usually the certificate report itself, because the customers have accepted it for years. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a quality system that means a few days with the quality manager and the inspectors, reading the database, the report definitions and the workbook, finding where each customer's rules live and what the next audit will ask for, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a quality and traceability system takeover What the assessment establishes for a quality system, and why each item matters: | Check | Why it matters | |---|---| | Where do each customer's certificate rules live: in the report, in the data, or with the quality manager? | The wording is a contract term. In the report definition, every new customer is a report change; nowhere, it is a risk. | | Which SQL Server and SSRS versions, on which Windows Server? | Windows Server 2016 ends in January 2027, and the report server is often the last machine anyone checked. | | Can the report definitions be opened, and does anyone know how to change them? | An SSRS report whose definition is lost can be re-created from its output, but the certificate is the one report the customers see. | | How is a heat number linked to its mill certificate, and where are the PDFs? | The link is the start of the trail. A folder named by year is a link that depends on a person. | | Is the gauge recorded against the inspection, or only in the register? | Without it, an out-of-tolerance gauge cannot recall the batches it measured, and the auditor knows to ask. | | How is a non-conformance closed, and who can close it? | The closure rule and the missing owner field are the two things the supplier audit asks about next. | | What does the next audit ask for that the system does not hold? | The accreditation and the customer audits set the stage order more than the technology does. | | Which despatches carry a concession, and how is that shown on the certificate? | A concession the certificate does not mention is a non-conformance of its own. It is a rule to find before anything moves. | ## Questions Q: We have an audit coming up. Can anything change before it? A: Yes, because nothing in the first stage changes what the auditor sees. The data moves to a supported database, the report definitions are secured and a test copy is built, and the certificates print as they always have. The visible changes come after, at a pace set around the audit dates. Q: Will the certificates of conformity still look the way the customers expect? A: Yes. The SSRS report keeps printing until the new certificate produces the same document from the same data, checked side by side. A layout a customer's goods-in has accepted for years stays until you choose to change it. Q: Our calibration register is a spreadsheet. Does it have to move? A: It is the first thing worth moving, because a gauge recall is the query the workbook cannot run. The register goes into the same database as the batches, column for column, and the inspector starts recording the gauge against the inspection from that day. The workbook stays until you trust the screen. Q: Can the auditor see the system? A: A read-only login for the day is one of the stages. The auditor picks a batch and follows the trail on screen, which takes less of the quality manager's day than driving the reports for them. --- # The shop-floor system your operators clock on to URL: https://www.solvewithsoftware.com/systems/manufacturing-engineering/shop-floor-data-capture-system Title: Shop-Floor Data Capture Modernisation Description: The program on the shop-floor terminals: clock on, clock off, scrap and job status, what modernising brings and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A shop-floor data capture system is the program on the terminals by the machines: operators clock on and off jobs with a barcode wand, and the bookings feed the office's job status, the job cost, the wages and the work-in-progress figure. Solve With Software takes over terminal systems written for one factory years ago, keeps them running, and modernises them in stages, so the operators keep the two scans they know while the office gets a floor it can see from anywhere and change without stopping a shift. AI helps first by checking each shift's bookings for the ones that do not add up before payroll runs, and the assessment prices each stage before you commit. The Old Guard: Written between 2000 and 2010 in VB6 or Delphi by a contractor, on PCs in steel cabinets by the machines, writing to a SQL Server shared with the office. The New Legacy: Tablets on arms, built between 2016 and 2022 by an agency in React, Angular or Node with a React Native or Ionic app, or in Power Apps. Where AI helps: Bookings checked before payroll: a three to four hour weekly hunt becomes five minutes a shift, which over ten shifts works out at two to three hours back. ## The program on the terminals Two buttons and a barcode wand, and it has run every shift since it was installed. A typical business running one of these has 40 to 150 staff across one or two factory units, 15 to 40 terminals by the machines, and between 500 and 3,000 bookings a day. Whether the booking screen was written for grey terminals in 2004 or for tablets in 2020, the job is the same. In the supervisor's words, the operator scans a badge, scans the job card, picks the operation and clocks on. At the end they clock off with the quantity made and the scrap, with a reason code. The terminal shows the next job queued for that machine, the office screen shows who is on what and which jobs are late, and at the end of the shift the hours go to payroll and the bonus calculation, the time goes against the job, and the accountant's work-in-progress figure updates itself. The rules it holds are the ones payroll would notice first: - An operator can be clocked on to two jobs at once on the multi-spindle machines, and the time is split in the ratio set for that machine. - The first fifteen minutes after a shift start book to the shift's overhead code, a leftover from how the bonus scheme was agreed. - Breaks are deducted automatically unless the operator clocked off, and the deduction differs by shift pattern. - A job cannot be clocked off complete when good plus scrap does not match the batch, unless a supervisor's badge overrides it, and the override is logged. - Certain scrap reason codes need a supervisor's scan before the terminal accepts them. None of that is in a document. It is in the program, and in the habits of the people who use it. ## The Old Guard: the program in the steel cabinet Written between 2000 and 2010 in Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) or Delphi (https://www.solvewithsoftware.com/modernise/delphi) by a contractor who came in to do the terminals and stayed for the supervisor screen. It writes to a SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) database shared with the office system that raises the works orders, and it runs as a Windows program on every terminal: a PC in a steel cabinet by the machine, with a serial wand or a keyboard wedge. It has been reinstalled on new terminals twice and changed by hand many more times. The contractor stopped answering years ago. The compiler lives on one machine in the office, and the connection string is compiled into the program, so the database cannot move without a new build on every terminal. That build has been put off at every budget meeting since. ## The New Legacy: tablets on arms, from about 2020 The same booking screen built between 2016 and 2022, usually by an agency or a freelancer as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) with a tablet app in React Native (https://www.solvewithsoftware.com/modernise/react-native) or Ionic (https://www.solvewithsoftware.com/modernise/ionic), or put together in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by a keen production engineer. Operators tap a tablet on an arm by the machine and scan the job card with its camera, the supervisor has the floor live on a big screen in the office, and payroll gets the hours as a download. From the office it looked as though the steel cabinets had had their day. The wifi is the first problem. Behind the press line, where the signal drops, a tablet booking made offline is lost rather than held, so those operators went back to paper cards. The last change, a night-shift break pattern, doubled some bookings and was switched off. The agency finished its fixed-price job and left, and where the app went through Google Play, updates have had to target Android 16 since 31 August 2026. Since 2023 a few production engineers have tried again with an AI app builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the split bookings and break rules payroll depends on. Each week payroll now merges the tablet download with the paper cards from behind the press line by hand. ## What does the office get from it? **A factory the office can see without walking round it, and wages that come from what was booked.** The terminals turned a walk across the floor and a card filled in from memory into a scan. The office knows which machine every job is on, how long it has been there and what is queued behind it, and the customer who rings for a delivery date gets an answer from the screen. The other half is money. Because the bookings feed payroll and the bonus, the wages are right and the arguments are rare. Because they feed the job cost, the estimator learns what a part took, and the work-in-progress figure at month end is a report rather than a count. Every efficiency number the owner looks at starts as an operator scanning a badge. Operators trust it because it asks little of them. Two scans and a quantity, no writing, and it has not changed in years. ## Why the terminals get left alone Systems like this are left alone for good reasons. The reasons are also the problem. **The database stopped getting updates in 2019.** The terminals write to SQL Server 2008 R2, which lost its updates in July 2019, on a server the terminals cannot be moved off because the connection string is compiled into the program. The insurer's questionnaire and the big customer's supplier audit both ask about it now. **A change is a shift at risk.** In either generation the booking screen runs on every terminal at once, so a bad update stops the floor at six in the morning. On the older program the last change, adding a scrap code, took a weekend, and nobody wants to be the person who tries the next one. **The office moved on and the floor stayed.** When the office went to a new works order system, the terminals kept reading the old table, so somebody exports the day's works orders into it every morning before the shift. If they are late, the floor clocks on to yesterday's jobs. **It shows a job number, not the job.** The terminal has no drawing, no work instruction and no photo of what good looks like, and the quantity is whatever the operator keys in, checked against nothing, so the job pack is still paper and the revision on it is whatever was printed. The supervisor can see the floor from the office screen and nowhere else. ## What does modernising the terminals bring? **The same two scans, on any screen, fed by whatever the office runs now.** Each of these keeps a rule the terminals already enforce. **The same clock-on screen, in a browser.** The same buttons in the same places, so it runs on the existing terminals, on a rugged tablet, and on the supervisor's phone. The wand still scans, and the split bookings and the break rules still apply. **Fed by the office system it has now.** Works orders read straight from whatever the office uses, so the morning export stops and the floor is never a day behind. When the office changes system again, the terminals change one connection, not one program on forty machines. **The right revision, checked at clock-on.** The drawing and the work instruction on the terminal when the operator clocks on, at the revision the works order carries, with a flag when the job card's revision is older than the current one. The paper pack becomes optional. **The machine's count beside the operator's.** Where the controller offers it, the cycle count from the machine sits next to the quantity the operator booked, so the count is confirmed rather than typed and the gap between them is visible the same shift. **A floor that can be changed on a Tuesday.** The database on a version that is still supported, the source in a place that builds, and a test floor of two terminals on a test copy, so a change is tried on two machines before it goes to forty. The scrap code that took a weekend takes an afternoon. None of this switches the terminals off. The new screen runs on two of them first, beside the old program on the rest, and moves across as the supervisors choose. ## What could AI do with a year of bookings? **Check them before payroll does, and put a finish date on every job from what the floor has already booked.** AI works on what the terminals record, never on the operators: **Bookings checked before the wages go.** An operator left clocked on for fourteen hours, a scrap quantity larger than the batch, a split booking with one half missing: today the supervisor hunts for them in the week's bookings before the payroll run. AI goes through every booking at the end of the shift, flags the ones that do not add up and suggests the correction, and the supervisor approves or changes it. On a floor booking 500 to 3,000 times a day, the hunt covers 2,500 to 15,000 bookings a week and takes a morning, three or four hours, before each weekly payroll. Approving the flags takes five minutes or so a shift, and at two shifts a day for five days that is under an hour, so the week works out at about two to three hours back. **An expected finish for every job.** The customer rings for a delivery date, and somebody walks the floor or phones the supervisor. AI works out an expected finish from the bookings so far and what the same part took last time, and shows it beside the job on the office screen. Each chase is ten minutes or so of walking and asking, and at four or five chases a day over a five-day week, that comes to about three to four hours a week. **The shift handover, drafted.** Which jobs are late, which machines stood idle, which overrides were used. AI drafts the note from the shift's bookings across 15 to 40 terminals, and the supervisor going off shift reads it and adds what the data cannot know. A quarter of an hour saved at one change of shift a day, five days a week, adds up to about an hour and a quarter a week. Not worth doing: predicting machine breakdowns from the booking data. There is not enough of it, and the maintenance fitter hears the bearing first. A flag or a finish date is only as sound as the tables it reads, and those sit on an unsupported server behind a compiled connection string, so this follows the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where it would pay back on the floor as it stands. ## How a takeover of the terminals runs The order is set by one fact: the floor cannot stop. 1. **Make it safe to change.** The source found and built on a machine that is not the one under the desk, the database moved off SQL Server 2008 R2 onto a version that is still supported, with the terminals still talking to it, a backup restored on purpose, and two terminals on a test copy. This goes first because a change that cannot be tried on two terminals cannot be tried at all. 2. **The feed from the office.** The first new piece touches no terminal: works orders read from the office's current system in place of the morning export. The floor notices only that yesterday's jobs stop appearing. 3. **The new screen on two terminals.** The clock-on screen in a browser, on two machines whose operators are willing, beside the old program everywhere else. When the supervisors prefer it, it spreads. 4. **Drawings, the phone view, the machine counts.** Each a stage, each priced on its own, each live on the test floor before the real one. 5. **Retire the old program** from the last terminal when nothing still runs it. The last thing to go is usually the end-of-shift payroll export, because payroll trusts it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a shop-floor system that means a few days on the floor and in the code, watching a shift clock on, reading the booking rules out of the program and finding what else writes to its tables, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a shop-floor data capture system takeover What the assessment establishes for a terminal system, and why each item matters: | Check | Why it matters | |---|---| | Is there source for the terminal program, and does it build on a machine that still exists? | Delphi and VB6 need their compiler and the components the contractor used. A program that runs but cannot be built can be read, and the options are set by that. | | Which SQL Server version, and what else writes to its tables? | SQL Server 2008 R2 lost its updates in July 2019. The office system, the payroll export and a report or two may all write to the same tables, and each is a link to keep. | | How do works orders reach the terminals: a shared table, a morning export, a file drop? | The feed is the first thing to modernise and the most fragile, and the person who runs it by hand is a single point of failure. | | What are the terminals running, and how is the barcode hardware connected? | A serial wand and a keyboard wedge behave differently in a browser. What the terminals can run decides whether they are kept. | | Which booking rules sit in the program rather than in the data? | Split bookings, break deductions and overrides decide wages. Each one has to be found before it can be kept. | | What feeds payroll and the bonus, and when does it run? | The most sensitive export in the building. It is tested before anything else moves. | | Can the floor clock on when the database is down? | Some terminal programs buffer bookings locally and some stop the floor. The answer sets how much resilience the new version needs. | | Which reports read the booking tables? | Efficiency, work in progress and the estimator's actuals all sit on them. A change to a column is a change to the month-end pack. | ## Questions Q: Can the operators keep using the same terminals and scanners? A: Usually, yes. If the terminals can run a browser, the new screen opens on them with the same wand, and nothing on the floor looks different. Where a terminal cannot, the assessment says so and prices the replacement as part of the stage. Q: The bonus scheme depends on the booking rules. Will they change? A: Not unless you ask. The rules come out of the program, get written down with the supervisors and payroll, and go into the new version as they are. The first weeks run both side by side so the wage figures can be compared line by line. Q: Our office moved to a new system. Can the terminals read from it? A: That is normally the first new piece. Most works order systems can be read directly or export on a schedule, and either replaces the morning export. The floor keeps clocking on the same way. Q: Can any of this happen without stopping the floor? A: Yes, and that is the whole shape of it. The first stage builds a test floor of two terminals so a change is tried there first, and every new piece runs beside the old program until the supervisors choose to switch. The old program is the fallback until nothing runs on it. --- # Systems that run construction and property businesses URL: https://www.solvewithsoftware.com/systems/construction-property Title: Construction and Property Software Description: The systems behind contractors, plant yards and managing agents, old and new, and where AI helps on each. From £395 + VAT. Last reviewed: 2026-09-14 Contractors, plant hire yards and managing agents run on systems built for one commercial office, one hire desk or one portfolio, usually years ago and usually by someone who knew the trade. Solve With Software takes those systems over and modernises them in stages, so the surveyors, the hire desk and the property managers keep the screens they know while the sites, the customers and the leaseholders get connected to them, and AI reads the invoices, timesheets and certificates that arrive every day. Each page below describes one kind of system in both its generations, and what modernising it brings. ## Where you find these systems Contractors, plant hire companies, specialist subcontractors and managing agents across the UK run on systems like these. Nearer home that means the groundworks and civils contractors along the A12 corridor between Colchester and Chelmsford, the plant yards outside Ipswich and the managing agents looking after blocks across Essex and the London fringe. Each has a system at its centre that was built for the way that one business works: a job costing database, a hire desk program, a rates library, a timesheet app, a block management system with a portal bolted on. And each has the same question about it: how to move it forward without missing a month end, a quarter day or a pay run. We work from Colchester and take on systems for businesses anywhere in the UK, remotely as a rule and on-site across Essex, Suffolk and London when the work needs it. The regional page (https://www.solvewithsoftware.com/essex-suffolk-london) says how the local side works. ## Built in the 2000s, or built since 2016 **The Old Guard** was written between the early 2000s and about 2013 by a contractor who had sat in the office it was for, or by an employee who knew Access and stayed late. The job costing ledger (https://www.solvewithsoftware.com/systems/construction-property/job-costing-valuations-system) is Access forms over SQL Server with Crystal Reports for the applications; the hire desk (https://www.solvewithsoftware.com/systems/construction-property/plant-hire-system) is Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) with a .NET yard screen bolted on; the rates library (https://www.solvewithsoftware.com/systems/construction-property/estimating-tender-system) is a VB6 program driving an Excel workbook; the block management system (https://www.solvewithsoftware.com/systems/construction-property/property-management-system) is Access with a Classic ASP (https://www.solvewithsoftware.com/modernise/classic-asp) portal beside it. **The New Legacy** is the same system built from about 2016 by an agency or a freelancer, in a browser with a site or driver app, or in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) because the licences were already paid for. The site diary app (https://www.solvewithsoftware.com/systems/construction-property/site-diary-timesheet-system) is often this generation on top of the older one. Since 2023 some offices have tried again with an AI builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the part with the money in it. Contractors and managing agents who run a bought package often have a homegrown system beside it for the rules the package does not hold, and that is the same kind of work. ## What modernising them tends to bring The sites get a phone that writes into the system: a diary with photos, a delivery with a signature, an off-hire with a number, a repair report with a picture. The office gets its numbers on the day rather than at month end: cost to date on a live contract, utilisation by category, every unit's demand previewed before it goes out. The rules the business runs on, retention percentages, minimum hire periods, waste allowances, apportionment schedules, come out of the code into tables the office can see and change. And the whole thing comes off the server in the corner, onto a supported database with a backup that has been restored on purpose, before the Windows Server 2016 date in January 2027 catches the ones still on it. After the first stage, with the system safe to change, AI can take the keying off the desk too: supplier invoices coded to the contract, photographed timesheets read into hours, contractors' certificates filed against the block, the client's bill matched to the rates library. Each system page works out the time that gives back for a typical office of its kind. None of it needs the old system switched off. Each piece is added beside it, on the same data, and the office moves a screen at a time. ## Questions Q: Can we keep running the business on the old system while it's modernised? A: Yes. The old screens keep running and each new piece is added beside them, on the same data. A site app, a customer view or a leaseholder portal can arrive without a single office screen changing, and the office moves a screen at a time once the new one is better than the old. Month end, the pay run and the quarter day never run on anything untested. Q: Our rules are in the code and our data is in an old file. Do we lose either? A: No. The rules are found first and written down with the people who apply them: retention percentages, minimum hire periods, waste allowances, apportionment schedules. Then they come out of the code into tables the office can see and change. The data comes off the old file onto a supported database with the old screens still pointing at it, and the new figures are checked against last month's before anything goes live. Q: Can the sites, the drivers and the leaseholders use it from a phone? A: Yes, and it is usually an early stage because it changes nothing in the office. A diary with photos, a delivery with a signature, an off-hire with a number or a repair report with a picture goes into the same system the office uses, and the office sees it on the screen it always used. Q: Is there anything AI could do for a system like ours? A: Yes, in the paperwork that arrives every day rather than in the judgement calls. It reads the supplier invoice, the photographed timesheet, the repair report or the contractor's certificate, and drafts the entry for someone to check instead of type. It can also answer the questions no report covers, such as which contracts have retention due back this quarter. It comes after the first stage, once the system can be changed safely, and the assessment maps where it would pay back on the system as it stands. Q: What does it cost, and how soon is something working? A: The assessment is from £395 + VAT, with an exact price before you commit, and it produces a report with costed options and a fixed price for each. The report is yours. Take it to us, another developer, or nobody. Each stage after that is priced on its own, and the first usually has something working within about six weeks. --- # The estimating system and rates library your tenders come from URL: https://www.solvewithsoftware.com/systems/construction-property/estimating-tender-system Title: Estimating System Modernisation Description: A contractor's estimating system: rates library, priced bill, adjudication, where AI matches bill items, and what modernising brings. From £395 + VAT. Last reviewed: 2026-09-14 An estimating and tender system is the rates library and the pricing screens every tender is priced from: the build-ups, the outputs, the material prices, the gang rates, the prelims, and the priced bill that goes back to the client. Solve With Software takes over estimating systems that grew from one estimator's workbook, keeps them pricing, and modernises them in stages, so the library that took twenty years to build comes out intact while the estimators get a screen that reads the client's bill in and sends it back priced. AI helps first before a rate goes in, matching each item on the client's bill to a build-up for the estimator to confirm. The assessment prices each stage before you commit. The Old Guard: A late-1990s Excel workbook, a VB6 program written around 2003 by a contractor, the rates library in Access by 2010, on estimating PCs held on old Office. The New Legacy: Replaced 2016 to 2022 by an agency or a freelancer with a browser system in PHP, .NET Core or React, or in Zoho Creator or Bubble by an estimator. Where AI helps: Bill items matched to the rates library: a thousand lines at 20 seconds saved on each works out at over five hours, a day's matching cut to a morning. ## A rates library with a program wrapped round it Two to four estimators, one director with a red pen, and a library that took twenty years to build. A typical business running one of these has 20 to 80 staff, an estimating department of two to four estimators and a director who adjudicates, and prices a tender or two a week, some of them a thousand lines long. The job is the same whichever generation built it: a 2003 program wrapped round a workbook prices a tender the way a 2020 browser system does. In the estimator's words, it takes the client's bill of quantities, usually measured to NRM2 or, on older work, SMM7, whether it arrives on paper, as a PDF, as Excel or from a tender portal, and prices each item from a build-up in the library or from a rate on a similar job. Prelims come from the programme, then overheads and profit. The director adjudicates on the summary sheet, the system spreads the adjustment across the rates, and the priced bill goes back in the client's format. The tender register records what was priced, for whom, at what margin, and whether it won. When a job is won, the figures go to the surveyors as the budget. The rules it holds are what make the library worth more than any package: - Every material carries a waste allowance of its own, set over years and different from any textbook figure. - Labour is priced as a gang, so a brickwork item carries two bricklayers and a labourer at the all-in rates updated each January, never a single rate. - Prelims are priced week by week from the programme, except on tenders below a value the director set, where a percentage is used. - The adjudication adjustment is spread across the rates after the sum, so the bill still adds up to the tender figure when the client checks it. - A rate carried over from a lost tender is flagged and cannot be reused until an estimator has reviewed it. Most of those numbers were set by one senior estimator, who is close to retiring. ## The Old Guard: VB6, Access and a workbook that never left It began as the senior estimator's Excel workbook (https://www.solvewithsoftware.com/modernise/excel-to-system) in the late 1990s. Around 2003 a contractor wrote a Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) program to hold the rates library and print the priced bill in the client's layout, and by about 2010 the library had moved into Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access). The workbook never went away. It still does the summing and the adjudication sheet, and the VB6 program drives Excel to fill it, on estimating PCs that sit on the same Office they had years ago, with the Access file on the office server. The contractor has gone, and no one since has had the source open. The development environment has been unsupported since 2008, so the program runs but cannot be changed with any confidence, and the link to Excel breaks whenever Office moves. The estimators have learned its moods and work round them. ## The New Legacy: rates on screen from 2020 Some contractors had the lot replaced between 2016 and 2022. A small agency or a freelancer built a web estimating system in PHP (https://www.solvewithsoftware.com/modernise/php), .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), with the rates library imported from the Access file, or an estimator who was handy with these things put one together in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Bubble (https://www.solvewithsoftware.com/rescue/bubble). The library opens in a browser, tenders are priced on screen, and nobody drives Excel from VB6 any more. From the estimating office it looked like the workbook's days were numbered. The bill import is usually where it stuck. It was written around the SMM7 bills the library grew up on, so NRM2 bills arrive with their items unmatched, and a change to one client's portal template broke the Excel route altogether. One adjustment to the spread left a priced bill a few pence out against the tender figure, and adjudication went back to the workbook that week and has stayed there. The freelancer who wrote it took a permanent job, and nobody has logged in to the server since. Since 2023 some estimators have tried a pricing screen of their own in an AI app builder, and the ones that stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) mostly did so short of the spread. ## What does it give the estimators? **A tender priced in days from a library no competitor has, and a bill that adds up when the client checks it.** Pricing from first principles takes weeks. Pricing from a library takes days, and the library is twenty years of what this business found the work cost, item by item. Two estimators price the same item the same way because they share the build-up, so a tender does not depend on who was in that week. The adjudication is where the director earns the margin, and the sheet in front of them comes from the same numbers as the bill, which is why they trust it. After the meeting the spread does the arithmetic the client will check. The register answers the question that comes up on every new enquiry: what was priced for this client last time, at what margin, and whether it won. ## Where it now gets in the way None of this has stopped. It has started to cost time. **The VB6 program and Office do not get on.** The VB6 development environment has been unsupported since 2008, and the program drives Excel through automation that an Office update can break. So the estimating PCs are kept on an old Office, and nobody upgrades anything on them in case the printing stops. **The library lives in one head.** The senior estimator built the build-ups over twenty years, and the outputs and waste allowances are written down nowhere except in the rates themselves. A new estimator cannot tell why a rate is what it is, and neither can the director. **Every tender is a copy of the workbook.** Each tender starts as a fresh copy of the pricing workbook, and the formulas drift between copies. A change to the prelims template has to be made in every live tender by hand, and a bill that arrives as Excel or through a client's portal is retyped in and retyped out. **The won job leaves the library behind.** Neither the VB6 program nor the browser system that followed it was ever joined to job costing. When a tender is won, the figures are retyped into the job costing system as a budget and the estimator's assumptions stay in the workbook. Six months later the surveyor is asking what the rate allowed for, and the estimator has moved on to the next tender. ## What would the estimators get from modernising it? **The same library and the same way of pricing, in a browser, with the workbook's job done inside the system.** Each of these comes from a rule or a habit the system already has. **The library written down and versioned.** Every build-up with its outputs, waste allowance and gang make-up, dated, with who changed it and why. The January rate update becomes one screen instead of a morning in Access, and the next estimator can see why a rate is what it is. **The client's bill read in, and priced back out in their format.** Excel bills and portal templates imported as items, PDF bills read and matched to the library for the estimator to confirm. The priced bill leaves in the layout it arrived in. **One tender, one place.** No copies of the workbook. Prelims priced from the programme inside the tender, overheads and profit applied once, the adjudication sheet drawn from the same numbers, the spread done by the system to the penny. **Handover without retyping.** A won tender becomes the job budget by cost code in the job costing system (https://www.solvewithsoftware.com/systems/construction-property/job-costing-valuations-system), with the estimator's assumptions attached to each item, so the surveyor can see what the rate allowed for. **A history you can ask questions of.** Every tender priced, for whom, at what margin, won or lost, in one place: which work types win, and which clients never award. **Out of the VB6 and off the pinned PCs.** The pricing screens in a browser, so an estimator can price from the client's office or from home, and the Office version on the desk stops mattering. The workbook and the VB6 program are not switched off for any of this. The new screens sit beside them, and the estimators move a tender at a time. ## Is there a job for AI in the estimating office? **Yes, in the reading and the looking back that come before the pricing: the client's bill, the tender documents and what was priced before.** The pricing itself stays with the estimators. **Bill items matched to the library.** A thousand-line bill arrives, and before a rate goes in the estimator works down it finding the build-up that fits each description, which is rarely worded the way the library words it. AI reads each item, proposes the build-up from the library and from similar items on past tenders, and marks the ones it is unsure of. The estimator confirms or changes the match rather than searches for it. On a thousand-line bill, half a minute a line finding the build-up comes to over eight hours, and ten seconds a line confirming one comes to under three: a day of matching becomes a morning of checking. **Tender documents read for what moves the price.** The preliminaries, the specification and the contract amendments run to hundreds of pages. AI lists the clauses that change the price, such as restricted working hours, access limits or unusual retention, with the page against each, for the estimator to read in full. With a tender or two a week, a four-hour first read-through cut to an hour with the flagged pages works out to three to six hours back a week. **Questions put to the tender history.** What did we price for this client last time, and at what margin? Which groundworks tenders did we win, and how far did adjudication move them? AI answers in plain words from the tender register and the priced bills, read-only so no rate moves, listing the tenders it drew on for the estimator to open. At one such question per tender, two or three hours in old workbook copies cut to a few minutes comes to roughly two to six hours a week. Not worth doing: AI pricing the tender. The estimator's judgement of the risk, the site and the client beats any model, and the client can tell. The library has to be secured, with a copy to try changes on, before anything reads from it, so AI waits for the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) says where it would pay back on the estimating system as it stands. ## How the stages run, library first The library first, then the screens, with the workbook beside them until the estimators stop opening it. 1. **Secure the library.** Out of the Access file and the VB6 program and onto a supported database, with every build-up intact and readable, the workbook's logic written down, a backup restored, and a test copy. This goes first because the library is the asset; everything after it is a way of using it. 2. **The pricing screen in a browser.** Against the same library, run beside the workbook until the estimators choose it for a live tender. 3. **Bills in and out, quotes in.** Import and export in the client's formats, and supplier quotes captured into material prices. 4. **Adjudication, handover, history.** Each a stage, each priced on its own, each live in weeks. 5. **Retire the VB6 program and the workbook** when nothing still depends on them. The last thing to go is usually the director's adjudication sheet. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an estimating system that means a few days with the estimators, the director and the code, finding how the library, the program and the workbook connect, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. Where the program needs keeping alive before any of this starts, legacy software support (https://www.solvewithsoftware.com/legacy-software-support) is the page for that. And if the question is whether to buy a package instead, replace or modernise (https://www.solvewithsoftware.com/problems/replace-or-modernise) sets out how to decide. ## The technical checklist for an estimating and tender system takeover What the assessment establishes for an estimating system, and why each item matters: | Check | Why it matters | |---|---| | Is the VB6 source available, and does it match the program on the estimators' PCs? | The development environment has been unsupported since 2008, and the source may be on a machine kept alive for it. | | How do the Access library, the VB6 program and the workbook connect? | Linked tables, VBA and Excel automation are the joints an Office update breaks. | | How many copies of the workbook are live, and do their formulas still agree? | Each copy is a tender. Drift between them is a pricing risk nobody can see. | | Where do the outputs, the waste allowances and the gang make-ups live, and who last changed them? | The library is the asset. If it exists only in the rates, it has to be reconstructed with the estimator who set it. | | How does the spread work after adjudication? | It is the arithmetic the client checks, and it has to come out to the penny. | | Which bill formats and measurement rules come in and go out? | Excel, PDF and portal templates are each an import or an export to build, and an NRM2 bill words and codes its items differently from an SMM7 one. | | Which Office and Windows versions are the estimating PCs pinned to? | They say what the automation depends on and what has been stopping the PCs from moving. | | Who owns the library, and who may change a rate? | The permissions and the stage order follow the people. | ## Questions Q: Our rates library is decades of work. Is it safe in this? A: It is the first thing secured and the reason the work starts from the system you have. Every build-up comes out with its outputs, waste and gang make-up intact, gets read through with the estimator who set it, and goes into a database where each change is dated and signed. Nothing is re-keyed. Q: Can the estimators keep using their workbook? A: Yes, for as long as they want to. The new pricing screen runs beside it against the same library, and the estimators move a tender at a time when the screen is better than the workbook. The workbook is retired last, if at all. Q: Can it read the bills clients send us? A: Excel bills and portal templates, yes, and PDF bills with the items matched to the library for the estimator to confirm. The priced bill goes back out in the same format it arrived in, which is the document the tender is judged on. Q: Wouldn't we be better off buying an estimating package? A: Sometimes, and the assessment will say so. The question is whether a package prices the way the business prices: gang rates, prelims from the programme, the spread, the waste allowances. Where the library is the edge, moving it into a package flattens it, and that is the case for modernising what exists. --- # The job costing and valuations system behind your month end URL: https://www.solvewithsoftware.com/systems/construction-property/job-costing-valuations-system Title: Job Costing System Modernisation Description: A contractor's job costing system: CIS, reverse charge, retention, where AI codes the invoices, and what modernising it brings. From £395 + VAT. Last reviewed: 2026-09-14 A job costing and valuations system is the commercial office's ledger for every live contract: the cost codes, the costs booked against them, the monthly application for payment, the retention held, the CIS deducted and the reverse charge applied. Solve With Software takes over systems like this, keeps month end running, and modernises them in stages, so the surveyors keep the contract screen they know while cost to date reaches the sites and the Sage link stops being a worry. AI helps first with the supplier invoices the ledger clerk keys by hand, reading and coding each one for a person to check. The assessment prices each stage before you commit. The Old Guard: Written 2004 to 2012 by a contractor or an employee who knew Access: Access forms over SQL Server, Crystal Reports and a Sage export, on the office server. The New Legacy: Rebuilt 2016 to 2022 by a small agency or a freelancer as a browser system in PHP, .NET Core or React, or in Zoho Creator or Power Apps by the office. Where AI helps: Supplier invoices read and coded on arrival: 60 to 80 a day at a minute and a half saved on each comes to an hour and a half to two hours a day. ## Inside a job costing and valuations system Two or three surveyors, one ledger clerk, and a month end that everything points at. A typical business running one of these has 30 to 120 staff, somewhere between 15 and 50 live contracts, a purchase ledger clerk posting 300 to 400 supplier invoices a week, and a commercial office of two or three quantity surveyors and a commercial director who reads the CVR before anyone else does. Written in 2006 or in 2019, it does the same job, and the office runs its month end on it the same way. In the surveyor's words, it sets up each contract with its cost codes, takes in the supplier invoices and subcontractor applications coded against them, records the monthly application for payment and what the client certified, holds the retention, deducts CIS at each subcontractor's rate, applies the VAT reverse charge where it belongs, and prints the cost value reconciliation the cost meeting argues over. The ledger clerk lives in the invoice screen. The surveyors live in the contract screen. The director reads one report. The rules it carries are the reason nobody has replaced it: - Retention is 5% to practical completion and 2.5% to the end of defects, except for two clients whose contracts say 3% throughout. - CIS is deducted from everything except the VAT and the materials the subcontractor bought, at the subcontractor's verified rate, so the materials element is keyed separately and left alone. - Since 1 March 2021 the VAT domestic reverse charge applies between VAT and CIS registered businesses unless the customer is the end user, so every contract carries an end-user flag that sets the VAT on invoices both ways. - Prelims are spread across the contract by week from the programme, never as a percentage of value. - A valuation is not invoiced until the payment certificate arrives, except for the one client whose application is treated as the invoice. None of that is in a manual. It is in the code, and in the head of whoever runs month end. ## The Old Guard: the Access ledger of the 2000s Written between 2004 and 2012, usually by a contractor who had sat in a quantity surveyor's office, or by an employee who knew Access and stayed late. Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) forms over a SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) database, Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports) for the application for payment and the CVR, and an export to Sage (https://www.solvewithsoftware.com/modernise/sage-integrations) at month end. Extended for years afterwards: a variations screen, a retention ledger, a CIS return export. It runs on a server in the office, with the front end copied onto each surveyor's PC and the reports on the ledger clerk's. Its last real change was the reverse charge in 2021, made in a hurry by whoever could be found, and the office has asked nothing of it since. The person who wrote it has retired or moved on, and the firm that looks after the network treats the database as outside its contract. The sites cannot see it, and the application goes out on paper or as a PDF typed into someone else's portal. ## The New Legacy: the contracts screen in a browser, 2019 Some contractors had the ledger rebuilt between 2016 and 2022, usually by a small agency or a freelancer, as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), PHP (https://www.solvewithsoftware.com/modernise/php) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), or assembled in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by someone in the commercial office. The contracts screen opens in a browser, the contracts managers have a login of their own, and subcontractors upload their applications to it. From the commercial office it looked like the month-end problem had been solved. Tax and accounts are usually what froze it. When the reverse charge arrived in March 2021 it went in as a line on the invoice layout instead of in the ledger, so the VAT return is corrected by hand every quarter. The Sage export was written for a version the business has since upgraded, and month end is back on a spreadsheet. Whoever wrote the code has moved on to other work, and the servers under it have gone years without an update. Since 2023 a few commercial directors have tried the whole thing again in an AI app builder, and those attempts (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) tend to stall at the retention arithmetic. The subcontractors still upload their applications to it, which is the main reason nobody has switched it off. ## Why does the commercial office depend on it? **The margin on every job before the month closes, and an application out on the day it is due.** A commercial office of three cannot hold fifty contracts in its head. The system does. Every invoice and every subcontractor application lands against a code, so when the surveyor opens a contract the cost to date is already sitting against the budget, and the CVR for the cost meeting comes from the same numbers rather than from three spreadsheets that disagree. The valuation side keeps the cash coming. The application for payment goes out in the client's layout on the contract's due date, with the retention arithmetic done and the previous certified value carried forward. Retention is a ledger rather than a memory, so the money due back at the end of the defects period gets chased. And because CIS and the reverse charge are worked out at the point of payment, the CIS return and the VAT return both match what went to the subcontractors. ## Where it has started to slip Systems like this do not fall over. They fall behind. **Month end goes through one PC.** The CVR and the applications come out of Crystal Reports on the ledger clerk's machine, and the run takes most of a morning with the Access front end locked for everyone else. Underneath it the database is usually SQL Server 2016, whose updates ended in July 2026, on a Windows Server 2016 that ends in January 2027. **The sites cannot see cost to date.** A contracts manager who wants to know what has been spent on a job asks a surveyor, who runs a query and emails a screenshot. Subcontractor applications arrive as PDFs and get keyed in by hand, so the figure is always a week or two behind the site. **The Sage link belongs to one version of Sage.** Whichever generation wrote it, the export was made for the Sage installed at the time, as a file layout, a COM link or a call to an interface that has since changed. Each upgrade is a held breath, and the accountant keeps last month's export files in case the new one fails. **The client portals want it typed again.** The larger clients now take applications through their own payment platforms, so the application the system prints gets retyped into a browser, line by line, on the due date. And from April 2029 business-to-business VAT invoices are due to go electronic, which neither generation was built to send. ## What would modernising it give the surveyors? **The same contracts and codes, in a browser, with the cost arriving the day it happens.** **Cost to date on the day.** The contract screen opened in a browser, on the same data, so a contracts manager on site sees what has been spent on the job without asking, and the surveyor stops emailing screenshots. The CVR runs whenever anyone wants it, in seconds rather than a morning. **Subcontractor applications straight in.** The subcontractor uploads or emails the application, the system reads the lines against the order, and the surveyor approves on screen with the PDF beside each line. **Retention with dates on it.** Practical completion and end of defects recorded against each contract, so the ledger says what is due back this month. The 5%, 2.5% and 3% rules move out of the code into a table the surveyors maintain. **The payment timetable, tracked.** Due dates, payment notices, pay less notices and the final date for payment held against every application, the ones the business makes to its clients and the ones its subcontractors make to it, so no notice is missed in either direction. Where the client uses a portal, the application goes out in the portal's format, and invoices leave electronically, ready for April 2029. **A Sage link that survives an upgrade.** The export matched to the Sage the business runs now, with last month's file kept as the comparison, so month end stops depending on last month's file. **Off the month-end PC.** The database on a version that is still supported, with a backup somebody has restored, and the Crystal reports replaced one at a time, so the run no longer needs the ledger clerk's machine. Neither the Access front end nor the 2019 screens are switched off for any of this. The system is added to, and the office moves screen by screen. ## Where would AI earn its keep on it? **The keying and the digging: invoices coded on arrival, certificates checked against what was applied for, and questions the CVR was never built to answer.** On a job costing system AI belongs in the paperwork and the lookups, not the judgement calls. Three places: **Supplier invoices coded on arrival.** At 300 to 400 invoices a week, the ledger clerk keys 60 to 80 a day: contract, cost code, lines, reverse charge or not. AI reads each PDF or photo and drafts the coding from the order and the supplier's history, and the clerk checks and posts. Keying takes a couple of minutes an invoice and checking about half a minute, so the saving on 60 to 80 a day comes to an hour and a half to two hours. **Payment certificates set against the application.** Each of the 15 to 50 live contracts brings back a certificate a month, often with a different figure on it. AI reads the certified value and the retention deducted, sets them beside what was applied for, and lists the lines that differ. At twenty minutes each by eye and five on the listed lines, 15 to 50 certificates a month works out at about four to twelve and a half hours saved. **Questions no report answers.** Which contracts have retention due back this quarter? Which subcontractors were paid more than their order last month? AI answers in plain words from the ledger, with read-only access, and lists the records behind each answer for the surveyor to check. Three or four such questions a week, each an hour of query and spreadsheet cut to a few minutes, comes to about three to four hours. Not worth doing: AI forecasting the final account. The surveyor's judgement of the site and the client beats any model at this size, and the cost meeting would not trust the figure. Every one of these reads the live ledger or writes to it, so none goes in before the ledger has a test copy and a backup somebody has restored. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows which would pay back first on the system as it stands. ## The order the work goes in Secure the database, then one process at a time, with the old screens as the fallback throughout. 1. **Stabilise.** The source found or recovered and matched to what the surveyors run, the database on a version that is still supported, a backup restored to prove it works, and a test copy of the whole system. This goes first because nothing can be changed safely until there is a copy that is not the live month end, and because it takes the January 2027 date off the list. 2. **The CVR and cost to date in a browser.** The first new piece is the one the surveyors and the contracts managers feel: the contract screen and the CVR against the same data, run beside the Crystal version until nobody opens the old one. 3. **Applications and invoices captured.** Subcontractor applications and supplier invoices arriving electronically, coded on the way in, approved on screen. 4. **Retention, the payment timetable, the portal export, the Sage link.** Each a stage, each priced on its own, each live in weeks. 5. **Retire the old front end** when nothing still depends on it. The last thing to go is usually an application layout one client has insisted on for years. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a job costing system that means a few days with the surveyors, the ledger clerk and the code, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. Where the system needs looking after before any of that starts, legacy software support (https://www.solvewithsoftware.com/legacy-software-support) covers it. ## The technical checklist for a job costing system takeover What the assessment establishes for a job costing and valuations system, and why each item matters: | Check | Why it matters | |---|---| | Is the Access front end's source available, and does it match what the surveyors are running? | Access systems get copied to each PC. The version on the ledger clerk's machine may be the only one with the month-end changes. | | Which SQL Server version, on which Windows Server, and where does the backup go? | SQL Server 2016 updates ended in July 2026 and Windows Server 2016 ends in January 2027. The backup has usually never been restored. | | Where do the cost code structure and the retention percentages live: tables, or code? | Rules in tables can move to a screen the surveyors own. Rules in code are the ones a rewrite loses. | | How is CIS calculated, and how is the monthly return produced? | The deduction rule and the return export are the two places an error costs money with HMRC. | | What produces the application for payment, and does each client have a layout of its own? | Crystal layouts carry rules. The application is the client's document and has to look the same the day after the change. | | How does the Sage export work, and which Sage version is it tied to? | Month end is the link finance cares about. It gets tested before anything else moves. | | How was the 2021 VAT reverse charge added, and where does the end-user flag live? | Every system of this age had to be changed for it in March 2021, often as a patch on the invoice layout. That patch is a rule to find before anything else moves. | | Who uses which screens, and who runs month end? | The stage order follows the people. If one person runs month end, the first stage removes that dependency. | ## Questions Q: Can we keep running month end on the old system while it's modernised? A: Yes. The Access front end and the Crystal reports keep working against the same database, and the new screens are built beside them. The surveyors move when the new CVR is better than the old one, and month end never runs on anything untested. Q: Our cost codes and retention rules are odd. Do we lose them? A: No. They are the first thing found and written down. Retention percentages, the CIS materials split, the end-user flags for the reverse charge, the prelims-by-week rule and the one client whose application is the invoice all come out of the code into tables the commercial office can see and change. Q: It exports to Sage. Will that still work? A: It is tested before anything else moves, because month end depends on it. The export is usually tied to one Sage version, and the new link is matched to the Sage the business runs now, with last month's export kept as the comparison. Q: Our surveyors keep a spreadsheet beside it for accruals. Can that go in? A: Usually, yes. The spreadsheet is a specification for a screen the system never had. Its columns and formulas get read through with the surveyor who built it and become part of the CVR. --- # The plant hire system that knows where every machine is URL: https://www.solvewithsoftware.com/systems/construction-property/plant-hire-system Title: Plant Hire System Modernisation Description: A plant hire system: register, LOLER dates, off-hire, invoicing, where AI reads hire requests, and what modernising it brings. From £395 + VAT. Last reviewed: 2026-09-14 A plant hire system is the hire desk's screen and the yard's memory: the register with its service and LOLER dates, every contract on hire, the day's deliveries and collections, the off-hire numbers and the invoice run. Solve With Software takes over hire systems written for one yard years ago, keeps them running, and modernises them in stages, so the desk keeps the screen it knows while the drivers, the customers and the machines start feeding it. AI helps first in the inbox, reading hire requests and purchase orders into draft contracts for the controller to confirm. The assessment prices each stage before you commit. The Old Guard: A VB6 hire desk written 2001 to 2006 by a contractor who had run one, .NET yard screens added around 2010, one database on the depot server. The New Legacy: Rebuilt 2016 to 2022 by an agency or a freelancer in React or .NET Core with a React Native driver app, or in Power Apps on licences already paid for. Where AI helps: Hire requests read from the inbox and drafted as contracts: 20 to 40 emailed a day at three minutes saved on each comes to one to two hours across the desk. ## What a plant hire system does all day One screen for the desk, one for transport, one for the workshop. A typical business running one of these has 15 to 50 staff, one or two depots, a fleet running to a few thousand items from breakers to twenty-tonne excavators, and a hire desk of two or three taking 40 to 80 hire requests and off-hire calls a day. Drivers move somewhere between 30 and 120 deliveries and collections a day, and a few dozen machines a month come in on cross-hire. Whether the desk went in during 2003 or 2018, the job it does is the same. In the controller's words, it holds the register: every machine with its fleet number, category, hours, service dates and thorough examination dates. It takes the hire, customer, site, delivery date, rate by day or week, delivery and collection charges, then prints the contract and the delivery note. Transport works the day's movements, the off-hire call gets a number, and the workshop logs damage on return. Then the invoice run, weekly or monthly in arrears, applies the minimum periods and the weekend rules and sends the lot to Sage. The rules it holds are what make it worth keeping: - Minimum hire is a week for excavators and dumpers and a day for breakers and small tools, whatever the off-hire date says. - A weekend counts as one chargeable day, and none at all if the off-hire call came in before three on the Friday. - Off-hire takes effect from the time of the call and the number issued; if transport cannot collect within two working days, the hire still stops. - Lifting equipment does not leave the yard past its LOLER thorough examination date: typically every six months for lifting accessories and anything that lifts people, every twelve for the rest. - A cross-hired machine goes on the customer's contract at the yard's rate, with the supplier's cost booked against the same contract, so the margin on it is known. None of it is written down anywhere else. The desk screen and the invoice run are the rulebook. ## The Old Guard: a VB6 desk with a .NET yard bolted on The hire desk was written between 2001 and 2006 in Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6), usually by a contractor who had run a hire desk himself and knew what a weekend rule was. Around 2010 the transport and workshop screens were added in .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework), often by the same contractor, so the system has two halves sharing one SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) database, with the invoice run exported to Sage (https://www.solvewithsoftware.com/modernise/sage-integrations) each week. It runs on a server in the depot office, and the delivery notes still print on the carbon-copy stationery. When the contractor retired, the support arrangement retired with him. Nobody ever wrote down how the two halves meet, so every change is a bet that the other half will not notice, and the depot stopped placing bets years ago. It cannot be opened from site, the drivers work from paper, and the machines' own hours never reach it. ## The New Legacy: the hire desk that moved online in 2018 The same desk built between 2016 and 2022, by a small agency or a freelancer, as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), with a driver app in React Native (https://www.solvewithsoftware.com/modernise/react-native). Some plant divisions used Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) instead, because the licences were already paid for. The desk opens in a browser, the drivers tap through a delivery note on a phone, and the bigger customers have a login that shows what is on hire. The customer login is often where it went wrong. It read from a copy of the contracts refreshed overnight, so a machine off-hired at ten still showed as on hire the next morning, and the site managers went back to ringing the desk. A later change to the weekend rule charged a customer for a Saturday, and with no tests to show what had moved, the rule was frozen where it stood. The agency that wrote it was bought, and the new owners quote for a rewrite instead of a fix. Since 2023 some hire firms have had an off-hire app half built in an AI app builder, and those projects (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) mostly stall where the app has to write back to the contracts. ## What does the yard get from it? **Every machine either earning or accounted for, and an invoice for every day it was out.** A hire desk of two or three cannot track a few thousand items across a hundred sites by memory. The register does it. Every machine is on hire, in the yard, in the workshop or cross-hired, and the screen says which, so when a customer rings for a dumper the desk knows in a moment whether one is free. The invoice run is the other half. Because the hire, the off-hire and the rules all sit in one place, the run bills everything that was out at the right rate, with the minimum periods and weekend rules applied every time. The off-hire number ends the argument about when a hire finished. The service and LOLER dates on the register keep the fleet legal without a separate diary, and the utilisation report by category is what decides what gets bought next spring. ## Where the strain shows Systems like this keep working. The world around them has moved. **The server went out of support in 2023.** Systems like this often sit on a Windows Server 2012, which ended in October 2023, with a SQL Server 2008 R2 underneath that lost its updates in July 2019. The insurer's questionnaire and the Cyber Essentials form both ask about it, and the office has run out of ways to answer. **Two halves, and nobody who knows which owns what.** The VB6 desk and the .NET transport screens talk through the database in ways the contractor never wrote down. A rate changed in one half shows up wrong in the other, so changes are now asked for only once something has already broken. **Site managers ring the desk for everything.** A site manager who wants to know what is on hire at their site, or wants a machine off, has to phone. The desk reads the list out, takes the off-hire, and writes the number on a pad in case of a dispute later. Half the desk's day is those calls. **The machines report to the manufacturer, not the system.** The newer excavators send hours and position to the manufacturer's portal. Neither the VB6 desk nor the browser version built later ever sees it, so the workshop keys hours from the drivers' notes and the service planner keeps a spreadsheet of the services and examinations due. ## What does modernising it bring the hire desk? **The same desk, in a browser, with the drivers, the customers and the machines feeding it.** Every one of these grows out of something the system already does. **Off-hire from the site manager's phone.** A login that shows what is on hire at each of their sites, an off-hire button, and the number back by text within the minute. The desk sees it on the screen it always used. **Deliveries and collections on the driver's phone.** Photos and a signature at each end, in the system before the lorry has left the site. A damage charge with a dated photo at each end is one that gets paid. **The register fed by the machines.** Hours and position from the telematics the fleet already has, written against the fleet number. Services fall due on real hours, the LOLER examination dates sit beside them with a warning before each lapses, and the planner's spreadsheet is retired. **Utilisation you can see.** Which categories earned last month and which sat in the yard, from the same data the invoice run uses. **Off the 2012 server.** The database and the server under it both on versions that are still supported, with a backup that has been restored on purpose, and an answer for the insurer's questionnaire. **One program instead of two halves.** The desk, transport and workshop screens opened in a browser, on the same data, with the minimum periods, the weekend rule, the cross-hire treatment and the customer rate cards in tables the desk can see and change. None of it needs the old programs switched off. Each piece goes in beside them. ## Where could AI save the hire desk time? **Hire requests in somebody else's layout, questions the desk answers by scrolling, and cross-hire invoices nobody wants to tick.** Three places stand out, none of them a decision about the fleet. **Hire requests read from the inbox.** A buyer emails for a dumper and a breaker from Monday, often with a purchase order attached, and the controller keys the contract by hand. AI reads the email and the order, matches customer, site and category, and drafts the contract at the customer's rate for the controller to check against the register. Of the 40 to 80 requests and calls a day, perhaps half arrive by email, and three minutes saved on each of those 20 to 40 emails comes to between one and two hours across the desk. **"What is on hire at the school job?" answered from the contracts.** Site managers ask it all day, along with what has run past its minimum hire. AI answers in plain words from the contracts and the off-hire numbers, with read-only access and no way to change a contract, listing each contract behind the answer, so the desk checks and sends instead of scrolling and reading out. With a hundred-odd live sites the desk might take 20 of those calls a day, and two or three minutes off each works out at forty minutes to an hour. **Cross-hire invoices checked against the contract.** The supplier's invoice arrives with its own dates and its own idea of when the hire ended. AI sets its dates and rate against the contract and flags anything charged past the off-hire number. Three or four dozen cross-hire invoices a month, each ten minutes of ticking cut to a minute or two on the flagged lines, comes to roughly five to seven hours saved at month end. Not worth doing: AI demand forecasting for the fleet. The desk knows the season and which sites are about to finish better than any model, and the utilisation report already says what sat in the yard. The invoice run has to be tried against a copy before anything new touches its data, which puts AI after the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) says which of the three would pay back soonest on this hire system. ## Stage by stage, with the old desk as the fallback Off the old server first, then one process at a time, with the VB6 desk running until the last stage. 1. **Stabilise.** Source for both halves found and matched to what is running, the database and the server under it on versions that are still supported, a backup restored, and a test copy of the whole thing. This goes first because the server date has already passed, and because the two halves cannot be changed safely until there is a copy to try it on. 2. **The driver app.** Deliveries and collections on a phone, writing into the existing database, with photos and a signature at each end. Not one desk screen changes. 3. **The customer view.** What is on hire per site, and off-hire from a phone, with the number sent back straight away. 4. **The desk in a browser, telematics, utilisation.** The desk and transport screens on the same data, run beside the old ones; the machines' hours into the register; the utilisation report. Each a stage, each priced on its own. 5. **Retire the VB6 and .NET programs** when nothing still depends on them. The last thing to go is usually the invoice run, once a month of new invoices has matched a month of old ones. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a plant hire system that means a few days with the desk, the workshop and both halves of the code, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. If keeping it alive is the first worry, legacy software support (https://www.solvewithsoftware.com/legacy-software-support) covers that. ## The technical checklist for a plant hire system takeover What the assessment establishes for a plant hire system, and why each item matters: | Check | Why it matters | |---|---| | Is the source for both halves available, and does each match the program running on the desk? | A VB6 half and a .NET half were often built years apart. One may have source on the old contractor's laptop and the other in a folder on the server. | | How do the two halves share the database, and which owns which tables? | Triggers and shared tables are where a change in one half breaks the other. They are found before anything is changed. | | Where do the rate cards, minimum periods and the weekend rule live? | Rules in code mean every price change is a developer change. In tables, the desk owns them. | | How does the invoice run work out the hire period, and where are the exceptions? | Minimum periods and the weekend rule are where the money is, and where a rewrite gets them wrong. | | Which Windows Server and SQL Server versions, and what else is on the box? | Windows Server 2012 ended in October 2023 and SQL Server 2008 R2 in July 2019. The insurer will keep asking. | | How does the Sage export work, and what does accounts do by hand around it? | The export is usually a file tied to one Sage version, with a spreadsheet that corrects it. | | What talks to the outside: telematics feeds, the customers' order portals, e-signature? | Each is an integration to keep working or to add. The telematics feed is the one that pays back first. | | Who uses which screens: desk, transport, workshop, accounts? | The stage order follows the people, and the driver app comes first because it changes nothing on the desk. | ## Questions Q: Can the hire desk keep taking hires while it's changed? A: Yes. The old programs keep running and the new pieces are built beside them on the same database. The driver app and the customer view arrive without a single desk screen changing, and the desk moves to the new screens when they are better, not before. Q: Half of it is VB6 and half .NET. Does that matter? A: It changes the order, not the outcome. The assessment finds how the two halves share the database and which rules live in each, so nothing gets rebuilt twice. Both are common enough to have their own pages on this site. Q: Can site managers off-hire online instead of ringing? A: Yes, and it is usually an early stage. A site manager sees what is on hire at their site, taps off-hire, and gets the number back straight away. The desk sees it on the same screen it always used. Q: Our rate cards and minimum periods are complicated. Do they survive? A: They are the reason the system is worth keeping. The minimum periods, the weekend rule, the cross-hire treatment and the customer rate cards come out of the code into tables the desk can see and change, and the invoice run is tested against last month's invoices before it goes live. --- # The block management system behind your portfolio URL: https://www.solvewithsoftware.com/systems/construction-property/property-management-system Title: Block Management System Modernisation Description: A block management system: service charges, client money, compliance, where AI files certificates, and what modernising it brings. From £395 + VAT. Last reviewed: 2026-09-14 A block management system holds a managing agent's portfolio: every block and unit, every lease and leaseholder, the service charge budgets and demands, the client money, the repairs and the compliance dates, with a portal the leaseholders log in to. Solve With Software takes over systems like this, keeps the demands going out on the quarter day, and modernises them in stages, so the property managers keep the screens they know while the demand run can be previewed and the compliance register takes any certificate. AI helps first with the certificates contractors send in, reading each one into the register against the right block for someone to check. The assessment prices each stage before you commit. The Old Guard: Access screens over SQL Server written around 2005 by a contractor who knew property, a Classic ASP portal added around 2008, all on the office server. The New Legacy: Built 2016 to 2022 by an agency or a freelancer in PHP, .NET Core or React, or in Zoho Creator by an accounts manager, with the portal in the same system. Where AI helps: Contractors' certificates read into the compliance register: two or three a working day at a quarter of an hour saved on each comes to 30 to 45 minutes a day. ## The system that holds the portfolio A few thousand leasehold flats, four quarter days a year, and a portal the leaseholders see before they see anyone in the office. A typical business running one of these has 10 to 40 staff and somewhere between a few hundred and a few thousand units across purpose-built blocks, converted houses and mixed estates, with property managers who each look after a patch of blocks, an accounts team running the client money, a maintenance desk taking the repairs, and several hundred compliance certificates arriving a year. Plenty of agents run a bought package; this is the system written for one agent's own portfolio. Built in 2005 or in 2019, it takes the same blocks through the same quarter days. In the property manager's words, it holds every block, unit, lease and leaseholder. It runs the service charge: the budget per block, each lease's schedule and percentage, the on-account demands, the reserve fund contributions, the year-end reconciliation and the balancing charges. It demands ground rent where the leases still carry it, chases arrears, keeps client money per block and reports to the freeholder or the residents' management company. It logs repairs, raises works orders and matches the contractors' invoices, and holds the compliance dates it was given fields for. The rules it holds are the ones a new property manager takes a year to learn: - Each block has apportionment schedules of its own: every unit pays into the estate schedule, only some pay into the lift schedule, and one block has a schedule with a single unit in it. - A works order that would cost any one leaseholder more than £250 is held for Section 20 consultation before it is raised. - Ground rent on one estate doubles on a fixed date under the lease, and the demand run knows the date. - Interest on late service charge is charged at the rate in the lease from the due date, but only after the second reminder has gone. - No service charge demand goes out without the statutory summary of leaseholders' rights and obligations, which the run attaches every time. The leases say some of that. The system is where the rest lives. ## The Old Guard: Access screens and a Classic ASP portal The office side was written around 2005, usually by a contractor who knew the property trade, as a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) front end over a SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) database. Around 2008 a Classic ASP (https://www.solvewithsoftware.com/modernise/classic-asp) portal went on beside it, so leaseholders and the directors of residents' management companies could log in for a statement and report a repair. Demands and letters come out of Word merge templates. The database, the portal and IIS all run on the server in the office, and the Access screens are copied onto each desk. The contractor answers slowly now, or has stopped answering. The portal's source may exist only on the web server itself, and VBScript, the language underneath it, is being retired from Windows. So the demand run is left alone, the portal is left alone, and every new requirement goes into a spreadsheet. ## The New Legacy: the portfolio system an agency built in 2019 The same system built between 2016 and 2022, by a small agency or a freelancer, as a web system in PHP (https://www.solvewithsoftware.com/modernise/php), .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), or put together in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) by an accounts manager who had seen what it could do. The office screens and the portal are one system in a browser, the demands go out as PDFs by email, and the leaseholders can pay online. To the property managers it felt like the Access years were over. The payments were usually the first thing to go. The payment provider retired the interface the portal used, the card button stopped working, and leaseholders went back to bank transfers with references nobody can match. Then a tweak to one block's apportionment put the wrong figure on a quarter's demands, and after the credit notes the demand run was declared off limits. Its developer left the agency that built it, and nobody there picked the system up. Since 2023 a few agents have had a leaseholder portal most of the way built with an AI app builder, and those builds (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) tend to stop at the point they must write to the ledger. Before each quarter day, accounts now export the demands to a spreadsheet and check every unit against last quarter's figure. ## What does it do for the managing agent? **Demands out on the day across the whole portfolio, and client money that reconciles.** An office of a dozen cannot apportion a few thousand units by hand four times a year. The system does it, block by block, schedule by schedule, and the demands go out on the quarter day in the form the lease and the law require. Arrears follow from the same ledger, so the reminders go to the right people with the right figures on them. The accounts side is what the auditor looks at. Client money is separated per block and reconciled, the report to the residents' management company and the leaseholder's statement come from the same ledger so they agree, and each block's year-end accounts start from the system. The compliance dates it holds surface before they lapse. And the portal takes the repair reports and shows the statements, so the phones ring less. ## Where it is wearing thin It still runs every quarter day. That is the point, and the problem. **The portal runs on a language being retired.** Classic ASP pages are written in VBScript, which Microsoft is retiring from Windows in phases: an optional feature now, planned to be off by default around 2027, and removed after that. The portal sits on IIS on a Windows Server 2016 that ends in January 2027, and it cannot take a photo with a repair report or a card payment, so leaseholders email instead. **The demand run is the thing nobody touches.** The apportionment schedules live in the demand run's code, so a new schedule is a developer change and there is no way to preview a run before the demands go out. The month before a quarter day, nothing in the system is changed at all. **The compliance list outgrew the date fields.** Whether the system was given its fixed set of certificate fields in 2005 or in 2019, the list has grown past them. Fire risk assessments, electrical installation reports, lift inspections, asbestos surveys and the building safety duties that came with the Building Safety Act 2022 live in a spreadsheet per block and on a wall planner. **Year end happens outside it.** Each block's service charge year end means exporting the ledger to Excel for the accountant, reconciling by hand, and typing the balancing charges back in. The client money reconciliation to the bank is done the same way, and the auditor asks about it every year. ## What does modernising it bring the portfolio? **The same portfolio and the same schedules, on a supported server, with the leaseholders, the contractors and the bank connected to it.** **A portal that takes a photo and a payment.** Statements, documents, a repair report with photos, a card payment, the directors' view for the residents' management company, all on the same database the office uses. The leaseholder emails stop, and the Classic ASP question goes away with the old pages. **A demand run you can change and preview.** The apportionment schedules in tables per block, the ground rent date and the interest rule beside them, and a dry run against a copy that shows every unit's figure against last quarter's before a single demand is sent. **A compliance register that takes any certificate.** Any type, its cycle, the contractor, the document itself, with a portfolio view of what lapses next month. The spreadsheet per block and the wall planner retire. **Repairs on the contractor's phone.** The works order sent to the contractor, photos back on completion, the invoice matched to the order, and the Section 20 threshold flagged before the order is raised. **Year end and client money from the system.** The bank feed reconciled against each client account daily, the year-end pack for the accountant produced from the ledger, and the balancing charges raised rather than typed. **Off the 2016 server.** The database and the server under it both on versions that are still supported, with a backup that has been restored on purpose, and the public face of the business no longer depending on the 2016 box. The Access screens are not switched off for any of this. Each piece is added beside them, and the demand run is the last to move. ## Which of the office's paperwork could AI take on? **The certificates and bank lines that arrive in other people's formats, and the questions nobody built a report for.** None of it touches the lease or the apportionment. AI reads what comes in and drafts what goes onto the system, and a person confirms it. **Certificates read into the compliance register.** Contractors send fire risk assessments, electrical installation reports, lift examinations and water risk assessments as PDFs, each in its own layout. AI reads the block, the type, the inspection date, the next due date and any remedial actions, and files them for a property manager to check. Several hundred certificates a year is two or three every working day, and twenty minutes of reading and keying on each cut to five of checking comes to 30 to 45 minutes between the property managers each day. **Payments matched after the quarter day.** Leaseholders pay by bank transfer with references that name the flat, the street, or nothing at all. AI reads each bank line against the demands that went out and proposes the unit. On 2,000 units, a minute a line by hand works out at over 30 hours of matching after each quarter day; if it leaves a couple of hundred lines unplaced, at two minutes each those take under seven hours. **Questions no report covers.** Which blocks have a fire risk assessment action still open past its date? Which leaseholders have had the second reminder but no interest charged yet? AI answers in plain words from the system's own records, which it reads and never writes to, and lists the units, orders and certificates behind each answer, so the property manager checks before acting. At five a week, each an hour of query and spreadsheet cut to a few minutes, that adds up to over four hours a week. Not worth doing: AI answering leaseholders' questions about their service charge. Those answers come from the lease, get argued at the tribunal, and a person sends them. The demand run needs a copy to be tried against before anything is wired into its data, so all of this follows the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) marks where on this block management system AI would pay back soonest. ## Server first, portal second, demand run last The demand run is not touched until there is a copy to try it on, so the stages that change nothing about it go first. 1. **Stabilise.** Source for the Access front end and the ASP portal found, the database and the server under it on versions that are still supported, a backup restored, and a test copy. This goes first because the server date is January 2027, and because the demand run cannot be changed safely until there is a copy that is not the live one. 2. **The portal.** A new one on the same data, taking photos and card payments. The first piece the leaseholders and the management company's directors feel, and it changes nothing on an office screen. 3. **The compliance register and repairs on the contractor's phone.** Each a stage, each priced on its own. 4. **The demand run and year end.** Apportionment in data with a preview, tested against last quarter's demands unit by unit, timed between quarter days with the old run still available; then year end and client money. 5. **Retire the Access front end** when nothing still depends on it. The last thing to go is usually the letter templates. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a block management system that means a few days with the property managers, the accounts team and the code, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. Where the contractor's silence is the first problem, legacy software support (https://www.solvewithsoftware.com/legacy-software-support) covers that. ## The technical checklist for a block management system takeover What the assessment establishes for a block management system, and why each item matters: | Check | Why it matters | |---|---| | Is the source available for the Access front end and the Classic ASP portal, and does each match what runs? | Two pieces built years apart. The portal's source may exist only on the web server itself. | | Where do the apportionment schedules live, in tables or in the demand run's code? | In the code, every new schedule is a developer change and the run cannot be previewed. | | How is the demand run produced, and what checks happen before the demands go out? | A wrong demand is a legal argument with every leaseholder in the block. The checks before the run are what the assessment writes down. | | Which Windows Server, IIS and SQL Server versions, and what else runs on the box? | Windows Server 2016 ends in January 2027, and the VBScript behind Classic ASP is being retired in phases. | | How is client money held per block, and how is it reconciled to the bank? | The regulator and the auditor ask. A spreadsheet answer is a finding waiting to happen. | | What produces the demands, letters and statements? | Word merge templates carry rules, and the demand is a legal document that has to look the same the day after the change. | | Which compliance dates does the system hold, and where do the rest live? | The spreadsheet per block is the specification for the register. | | Who uses which screens: property managers, accounts, the maintenance desk, the portal users? | The stage order follows the people, and the portal comes early because it changes nothing in the office. | ## Questions Q: We run a small lettings book on the same system. Can it cope with this year's changes? A: Usually not without work, which is one reason most agents run lettings on a bought package. On 1 May 2026 the Renters' Rights Act turned every assured shorthold tenancy into an assured periodic tenancy, so fixed-term end dates and renewal letters stopped meaning anything, and since 6 April 2026 landlords with qualifying income over £50,000 have been in Making Tax Digital for Income Tax, with quarterly updates a homegrown statement run was never built to feed. The assessment says whether that side is worth changing or better moved to a package. Q: The service charge apportionments are in the code. How do we keep them? A: They are found first and written down block by block with the property managers who know them. Then they move into tables the accounts team can see, and the new demand run is tested against last quarter's demands until every unit's figure matches before it is used for real. Q: Our demands go out on fixed quarter days. When is it safe to change anything? A: Nothing touches the live demand run without a test copy first, and the stage that changes it is timed between quarter days, with the old run still available. The earlier stages, coming off the 2016 server and the portal, change nothing about how the demands are produced. Q: Should we move to an off-the-shelf block management package instead? A: Sometimes, and the assessment says so when it is true. The test is whether a package carries the schedules, the ground rent dates and the statement rules the business runs on, and what migrating the ledger and the client money would cost. Where the system fits and the server underneath is the problem, modernising is usually the cheaper route. --- # The site diary and timesheet system your sites fill in each day URL: https://www.solvewithsoftware.com/systems/construction-property/site-diary-timesheet-system Title: Site Diary System Modernisation Description: A site diary and timesheet system: site app, approvals, payroll, where AI reads paper timesheets, and what modernising it brings. From £395 + VAT. Last reviewed: 2026-09-14 A site diary and timesheet system is how the sites tell the office what happened today: who was there and for how long, what arrived, what was delayed and which plant ran, with a phone app on each site and a pay run at the end of the week. Solve With Software takes over systems like this when the app can no longer be built and the Access file underneath has started to lock, and modernises them in stages, so the sites keep the diary they know while the office gets an app that installs and a pay run straight out of approved hours. AI helps first with the photographed paper timesheets, reading them into lines for the payroll clerk to check. The assessment prices each stage before you commit. The Old Guard: An Excel timesheet moved into Access around 2008 by someone in the office, a PhoneGap app added 2011 to 2013, all on the office server and shared drive. The New Legacy: Rebuilt 2019 to 2022 by an agency or a freelancer as a browser system with an Ionic or React Native site app, or put together in Power Apps by the office. Where AI helps: Paper timesheets read into draft lines: five to ten sheets a day at six minutes saved on each comes to half an hour to an hour for the payroll clerk. ## From the site's phone to Thursday's pay run A phone on every site, a spreadsheet in the labour office, and a pay run on Thursday that depends on both. A typical business running one of these has 40 to 150 people on the books, labour-only subcontractors included, somewhere between eight and twenty live sites, a labour manager, a payroll clerk and contracts managers who each look after a handful of sites. The diary lines run to a few hundred a day, and most days a handful of gangs still send a photographed paper sheet. Whether it is an Access file with an app bolted on or a browser system with an app of its own, the week it runs is the same. In the labour manager's words, it allocates gangs to sites for the week, takes each site's daily diary from the app, weather, visitors, deliveries, delays, plant on site, who was there and for how long, turns the hours into timesheet lines for the contracts manager to approve, sends the approved PAYE hours to the payroll package, and pays the labour-only subcontractors weekly less CIS. Every hour is costed to a site, and the diary feeds the weekly report the client's project manager expects on a Friday. The rules it applies are the ones a new payroll clerk takes a year to learn: - Overtime starts after 39 hours in the week, except for the gangs on price, who get none. - Travel is paid from the yard for sites beyond a set distance, and lodge beyond a further one, both measured from the yard rather than the operative's home. - A day is locked once the contracts manager approves it; anything after that goes through a correction line the following week. - A diary with no entry on a day the site was open is chased on the Monday, and that day's hours are held until it is in. - Gangs on price are paid on measure, so their hours are recorded for costing but never paid. Most of that is in the code and the payroll clerk's head, and the week's allocation is usually still a spreadsheet on the labour manager's second screen. ## The Old Guard: an Access file with a PhoneGap app on top It started as an Excel timesheet (https://www.solvewithsoftware.com/modernise/excel-to-system) in the late 1990s and moved into Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) around 2008, built by someone in the office who knew Access and was given the job. Between 2011 and 2013 a local agency added a PhoneGap (https://www.solvewithsoftware.com/modernise/phonegap-cordova) app so the site managers could fill in the diary and the gang's hours on a phone, posting to a small web service on the office server that writes into the Access database. The office side is still a set of Access forms, a desktop program that wants to be a web one (https://www.solvewithsoftware.com/modernise/desktop-to-web), with the file on the shared drive. The labour board stayed in Excel. The agency moved on and the tooling the app was built with has gone, so the app can only be kept on the phones that already have it. The web service in the middle has no documentation and no owner. Every new user in the Access file brings the Thursday lock closer. ## The New Legacy: the 2019 rebuild with a proper site app Some contractors replaced the lot between 2019 and 2022. A small agency or a freelancer rebuilt the office side as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), with a site app in Ionic (https://www.solvewithsoftware.com/modernise/ionic) or React Native (https://www.solvewithsoftware.com/modernise/react-native), or the office put its own together in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) because everyone already had a login for it. From the labour office it looks settled: timesheets approved in a browser, photos on the diary, no Access file to lock on a Thursday. The site app is what stopped it. Last built in 2022, it cannot be updated under the 2026 store rules without a rebuild nobody has quoted for, so a site manager with a new phone is back to photographing paper. When the travel distances changed, the app and the office screens measured them differently and paid a gang lodge they had not claimed, and the rule has been left alone since. The agency closed, and the hosting renews each year without anyone logging in. The labour board, promised for a second phase, never came, and since 2023 a few labour managers have tried to build it themselves in an AI app builder; those efforts (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) usually stop where the board has to write into payroll. Diaries from before the rebuild never came across, so a delay claim on an older job still goes back to the Access file. ## Why does the office run the week from it? **A pay run that goes out on Thursday with every hour costed to a site, and a diary that stands up a year later.** Without the system, the hours would arrive as photographs of paper and someone would type them for two days. With it, the site manager's phone is the timesheet, the contracts manager's approval locks the day, and the payroll clerk exports rather than types. Every hour lands on a site, so the surveyors' cost to date includes labour, which is the biggest number on most jobs. When the client's project manager disputes a delay from last March, the answer is the diary line for that day: the weather, the delivery that never arrived, the plant that stood idle. The labour board answers the other daily question, who is where tomorrow, before the phones start at six. And because the subcontractor payments come from approved hours, the CIS statements match the money that went out. ## The parts that no longer keep up Some of it has broken. The rest has frayed. **The app cannot be rebuilt.** Adobe shut PhoneGap down in 2020. Since 28 April 2026 App Store uploads have had to be built with Xcode 26, and from 31 August 2026 Google Play updates must target Android 16. A site manager with a new phone cannot install the app, so that site is back to a paper sheet photographed and sent on WhatsApp for the office to type in. **The Access file goes read-only on a Thursday.** With several site managers, the contracts managers and payroll all in one file on the shared drive, it locks or corrupts, and somebody runs compact and repair while everyone waits. **The labour board never made it in.** Neither the Access version nor the later rebuild took it on. Allocation is still done in the labour manager's spreadsheet and re-keyed into the system on a Monday. The sites find out who they are getting by phone, and the spreadsheet and the system disagree by Wednesday. **The diary has words but no pictures.** The app took photos, but the Access file could not hold them and the upload was the first thing to break. So the delay claim has a diary line and a folder of photos on a phone that has since been replaced. ## What would modernising it change? **The same diary and the same rules, on a phone that installs, feeding a database that does not lock.** Each of these is something the system already tries to do. **A site app that installs on any phone.** One the sites can install this year and next, writing into the same database, working in a hole in the ground with no signal and syncing when it finds one. The site manager fills in the same diary. **Photos in the diary.** The day's photos attached to the day's entry, stored with the record rather than on the phone. The delay claim stands on the diary again. **The labour board inside the system.** Gangs dragged onto sites for the week on one screen, with tomorrow's allocation on the site manager's phone by the evening before. The spreadsheet and the system stop disagreeing because there is only one of them. **Approvals from wherever the contracts manager is.** Hours approved on the phone from the site, the day locked at that moment, the correction line still there for the week after. **Payroll and subcontractor statements straight out of approved hours.** The export in the payroll package's own format, the weekly subcontractor statement with CIS deducted, both produced rather than assembled. **Off the Access file.** The data on a supported database, the office screens in a browser, the Thursday lock gone and compact and repair a memory. The Access forms and the old app are not switched off for any of this. The new pieces go in beside them, and the sites move one at a time. ## What could AI do with the diaries and timesheets? **Read what the sites send in, whatever shape it arrives in, and turn weeks and months of diary lines into something a person can check.** A diary system collects more words than anyone in the office has time to read, and that is where AI earns its place. **Paper timesheets read into timesheet lines.** Some gangs will always send a photographed sheet, app or no app. AI reads the photo, matches the names to the operatives on that site and drafts the lines, marking anything it could not read, so the payroll clerk checks instead of typing names, days and hours. At about seven minutes to type a sheet and one to check it, five to ten sheets a day comes to half an hour to an hour saved each day before Thursday. **The client's weekly report drafted from the diary.** Every Friday each site manager turns five days of entries into the progress report the client's project manager expects. AI drafts it from the entries and the photos, and the site manager corrects and sends it. At about two hours to write one and half an hour to read a draft, 8 to 20 sites works out at 12 to 30 hours a week saved between them. **A delay chronology pulled together when the claim comes.** When an extension of time is argued, somebody reads months of diary lines to rebuild the story of the weather and the late deliveries. A site writing about 20 lines a working day builds up some 2,500 in six months. AI drafts the chronology with each line and photo cited against its date, and the surveyor checks it. At a minute a line, reading them all comes to about 40 hours; checking the cited lines at 15 seconds each, about ten. Not worth doing: AI predicting labour demand per site. The labour manager's knowledge of the programme and the gangs beats any model at this size. Thursday's pay run reads the same data, so none of this is switched on until changes can be tried on a copy first. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) finds where on this diary system AI would pay back soonest. ## The order it happens in Data first, then the app, then the office, with the old forms as the fallback until the end. 1. **Stabilise.** The data off the Access file and onto a supported database, with the office forms left pointing at it, the app's source and the web service it talks to found and written down, a backup restored, and a test copy. This goes first because an app cannot be rebuilt against a file that locks, and because the Thursday pay run depends on the data underneath. 2. **The site app.** A new one on the same database, with photos and offline working, run beside the old app on the phones that still have it. 3. **The labour board and approvals in a browser.** Allocation and approval on one screen, with tomorrow's allocation on the phone. 4. **Payroll export, subcontractor statements, the weekly diary report.** Each a stage, each priced on its own, each live in weeks. 5. **Retire the Access forms and the labour spreadsheet** when nothing still depends on them. The last thing to go is usually the payroll clerk's export, once it has matched the old one for a few weeks. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a site diary and timesheet system that means a few days with the labour manager, the payroll clerk, a site manager or two and the code, finding the pay rules, the web service and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. If the agency's silence is the first problem, legacy software support (https://www.solvewithsoftware.com/legacy-software-support) covers that. ## The technical checklist for a site diary and timesheet system takeover What the assessment establishes for a site diary and timesheet system, and why each item matters: | Check | Why it matters | |---|---| | Is the app's source available, and can it be built at all? | PhoneGap Build closed in 2020. An app without a build pipeline cannot be updated for the store requirements that arrived in 2026. | | What does the app talk to, and where does that run? | Usually a small web service on a server in the office. It is the piece nobody remembers exists until it stops. | | Is the Access file split into front end and back end, how big is it, and how many people are in it at once? | Size and concurrent users are what make it go read-only on a Thursday. | | Where do the pay rules live: overtime, travel, lodge, price work? | Rules in VBA or in the app's code are the ones a rewrite loses. | | How is the payroll export produced, and what happens by hand between the system and the payroll package? | The pay run is the link finance cares about. It gets tested before anything else moves. | | What does the labour board spreadsheet do that the system does not? | Its formulas are the specification for the allocation screen. | | Where are the photos? | A folder on a phone is evidence nobody can find when the claim comes. | | Who approves what, and when are hours locked? | The approval step is what makes the diary evidence rather than opinion. | ## Questions Q: Our site managers' new phones can't install the app. Can it be patched, or does it need rebuilding? A: Rebuilding, in most cases. PhoneGap has had no build pipeline since 2020 and the store requirements moved on in 2026, so there is nothing to patch against. The new app writes to the same database, so the office side does not change on the day the sites switch. Q: Can the sites keep using paper timesheets while this happens? A: Yes. Nothing on the sites changes until the new app is ready, and the sites that prefer paper can carry on afterwards, with the photographed sheet read into the system for the clerk to check. Q: The overtime, travel and lodge rules are ours. Where do they go? A: Into tables the office can see and change. They are found first, in the VBA and the app's code, and written down with the payroll clerk who applies them. A rewrite from scratch is where rules like that get lost, which is why the work starts from the system you have. Q: Will payroll still run on Thursday? A: Yes. The pay run is tested against a previous week before anything moves, and the export to the payroll package is the first link checked. The old forms stay available until the new export has matched the old one. --- # Systems that run wholesale and distribution businesses URL: https://www.solvewithsoftware.com/systems/wholesale-distribution Title: Systems Behind Wholesale Distributors Description: The systems that run wholesalers and distributors, old and new, trade counter to B2B portal, and where AI helps on each. From £395 + VAT. Last reviewed: 2026-09-14 Wholesalers and distributors run on systems that hold the price book, the stock figure and the rounds, usually written years ago for one counter or one warehouse and extended every year since. Solve With Software takes those systems over and modernises them in stages, so the counter, the buyer and the drivers keep the screens they know while the customers, the branch and the accounts get connected to them, and AI turns the emailed lists and PDF orders into orders for someone to check. The pages below take those systems one at a time, in both their generations, and say what modernising each brings. ## Where the counters and the warehouses are Builders' and plumbers' merchants, electrical and industrial wholesalers, food and drink distributors and catering suppliers run on systems like these in every region of the UK. Nearer home they sit on the estates around Chelmsford, Colchester, Braintree and Witham, along the A12 and out to the M25 fringe where the London deliveries begin. Each has a trade counter or a warehouse with a system at its centre that knows every account's price and every product's location, and each has the same question about it: how do we bring it forward without the counter stopping or the vans standing? Our base is Colchester; the counter or the warehouse can be anywhere in the UK. The work runs remotely, with a visit in person across Essex, Suffolk and London when the system needs one, and the regional page (https://www.solvewithsoftware.com/essex-suffolk-london) says how that works locally. ## Two generations behind the counter **The Old Guard** was written between the early 2000s and about 2013 by a contractor or a small software house that has since folded. The trade counter system (https://www.solvewithsoftware.com/systems/wholesale-distribution/trade-counter-order-system) is a Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) program with Crystal invoices; the stock and purchasing system (https://www.solvewithsoftware.com/systems/wholesale-distribution/stock-purchasing-system) is Access for the buyer and a .NET program at goods-in; the rounds system (https://www.solvewithsoftware.com/systems/wholesale-distribution/van-sales-delivery-system) has a Cordova app on rugged handhelds; the ordering portal (https://www.solvewithsoftware.com/systems/wholesale-distribution/b2b-ordering-portal) is Classic ASP (https://www.solvewithsoftware.com/modernise/classic-asp) with Web Forms on top. **The New Legacy** is the same system built from about 2016 by a web agency or a freelancer: an order screen in a browser, a scanner app on ordinary phones, a portal that works on a buyer's phone, or a low-code build in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or Zoho Creator. Since 2023 a few have been attempted in an AI builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) before the Sage link. It looks modern, and nobody can change it. Most merchants and distributors of this size run a bought trade package for some of this, often with a homegrown price book, portal or rounds app beside it. That homegrown piece is the same kind of work. ## What comes out of modernising them The price book comes out of the code into screens the sales office owns, so a new price for a big account takes minutes. The stock figure becomes one figure, at every location, because goods-in, the pick and the transfer are scanned as they happen. The drivers get an app that installs on a phone that can be replaced, and the office sees the drops during the day instead of at six. The customers get live stock on the portal, confirmations that send themselves, and EDI feeds in the formats the national accounts now ask for. And the whole thing comes off the one PC and the server with a date on it, onto a supported database with a backup that has been restored on purpose. Once the system can be changed safely, AI takes the keying off the sales office and the buyer too: an emailed list or a PDF purchase order drafted into an order with the codes matched, a supplier's price list read into new costs, a customer's doorstep note read into a standing order. Each system page works out the time that gives back at its own order volumes. None of it needs the old system switched off. Each piece is added beside it, on the same data, and the counter, the warehouse and the drivers switch when the new screen is better than the old one. ## Questions Q: Will the counter or the warehouse have to stop while the system is modernised? A: No. Each new piece goes in beside the old system, on the same data, and the counter, the pickers and the drivers switch when the new screen is quicker than the one they have. The old program stays as the fallback until nothing still opens it. Q: Our prices, reorder levels and round rules are all inside the old system. Do they survive? A: They are the first thing found and the last thing changed. The assessment writes them down with the people who use them, and they go into data the office can see and maintain rather than code only one developer could read. A contract price or a substitution pair that has held for years keeps holding. Q: We have a counter system, a stock system and a portal, and they all need work. Which goes first? A: The one with a date on it. A server that goes out of support in January 2027, a handheld app that will not install on a new phone or an EDI line that ends with the analogue switch-off sets the order, and the assessment says which. Where nothing has a date, the piece the customers feel usually goes first. Q: Half our orders still arrive as emails and PDFs. Can AI do anything with a system like ours? A: Yes, once the system is safe to change. On systems like these it reads what already arrives in writing, the electrician's emailed list, the buyer's PDF purchase order, the supplier's new price list, the note a customer hands the driver, and drafts the order or the update for someone to check rather than type. It can also hold an order that does not look like that customer before it is picked. In a sales office where half the orders arrive that way, the keying is the first part of every morning. It comes after the first stage, and the assessment maps where it would pay back on the system as it stands. Q: What does it cost, and how soon does something work? A: The assessment is from £395 + VAT, with an exact price before you commit, and it produces costed options with a fixed price for each. The first stage is sized so something is working in about six weeks. The report is yours. Take it to us, another developer, or nobody. --- # The ordering portal and EDI feed that take your customers' orders URL: https://www.solvewithsoftware.com/systems/wholesale-distribution/b2b-ordering-portal Title: B2B Ordering Portal Modernisation Description: A wholesaler's trade ordering portal and EDI feeds: what they give the business, where AI helps and what modernising brings. From £395 + VAT. Last reviewed: 2026-09-14 A B2B ordering portal is the wholesaler's counter that never closes: trade customers log in to their own prices and stock and order at any hour, and the EDI feed does the same for the national accounts whose orders arrive as files. Solve With Software takes over portals and EDI links built in stages by different agencies, keeps them running, and modernises them one screen at a time behind the same address, so customers keep their login while the business gets live stock and feeds the big accounts accept. AI helps first with the purchase orders that still arrive as emailed PDFs, drafting each into the portal for the sales office to confirm. The assessment prices each stage before you commit. The Old Guard: Classic ASP from 2006, rebuilt in ASP.NET Web Forms around 2011 with a PHP catalogue added, on an IIS server in the office beside the EDI script. The New Legacy: Built 2016 to 2022 by a web agency in React, Node or early .NET Core, or in Bubble, with the EDI left on the old translator script. Where AI helps: AI drafts emailed PDF orders into the portal: two to four dozen a week at about ten minutes each to key comes to about four to eight hours of the week. ## What the portal and the EDI feed do Two doors into the same order book. One the customers walk through with a login; one the national accounts send files through, and nobody walks through at all. A typical business running one of these has 20 to 100 staff, a portal used by a few hundred trade accounts that places a third to a half of the order lines, and EDI with a handful of national accounts, multiples, buying groups or large contractors, that make up a large share of turnover. Several hundred portal orders a week, the EDI orders in batches each morning, and a few dozen a week still arriving as emailed PDFs from accounts that use neither. Whichever generation built it, a Classic ASP site from 2006 or an agency's portal from 2019, the job is the same and the order book fills the same way. From the customer's side, it shows their own price for each product they are set up for, a stock traffic light, their favourites and their last order. They fill a basket, check out with a PO reference and a delivery date, and the order lands in the sales order system like any other. They can see where it is and download the invoice. On the EDI side, the files arrive, the translator maps the account's codes to ours and raises the orders, sends the acknowledgement, and later the despatch advice and the invoice in the format that account mandates. A file that fails lands in a folder, for the one person who knows what to do with it. The rules it holds: - Each customer sees its own price and only the product groups it has been set up for. - An order over a customer's usual size, or with a delivery date before the cut-off, is held for the sales office to look at. - The national accounts' product codes are mapped to ours, and the mapping has exceptions per delivery depot. - Stock shows as traffic lights, never numbers, and the thresholds differ by product group. - Invoices go to one account as a file per delivery and to another as one file a week. ## The Old Guard: Classic ASP from 2006, with Web Forms on top The first portal was written in 2006 in Classic ASP (https://www.solvewithsoftware.com/modernise/classic-asp) by the contractor who wrote the order system. A small agency rebuilt it around 2011 in ASP.NET Web Forms (https://www.solvewithsoftware.com/modernise/aspnet-web-forms), and a web agency bolted on a PHP (https://www.solvewithsoftware.com/modernise/php) catalogue after that. Prices and stock come across from the order system's SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) in a nightly copy, the EDI translator is a mapping script on the same IIS server in the office, and parts of the 2006 site are still live behind the newer pages. Three agencies have come and gone, each leaving its own code and nobody's notes. The login works across all three through a fix nobody documented, so the checkout is left exactly as it is. It was laid out for a desktop monitor in 2012, and on a buyer's phone it shows. ## The New Legacy: the agency portal that launched in 2019 The same portal built between 2016 and 2022, usually by a web agency or a freelancer, as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) or early .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), sometimes with an ordering app for the trade buyers in React Native (https://www.solvewithsoftware.com/modernise/react-native). A few wholesalers had a customer portal put together in Bubble (https://www.solvewithsoftware.com/rescue/bubble) instead, reading the order system through a connector someone set up. From the office it looks modern: a clean catalogue, a basket that works on a phone, stock refreshed through the day. Since 2023 some have had a reorder screen started in an AI app builder, which showed a customer's favourites and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the hold rules. Half of it never moved. The agency quoted for the catalogue and the basket but never for the EDI, so the national accounts' orders still run through the old translator script, on an old server kept alive for that alone. A later change to the new checkout let a large order skip the hold and go straight to picking, and nothing has been released since. The agency was absorbed into a bigger one, and its packages date from launch. Meanwhile the sales office reads every large portal order by eye before it reaches the warehouse. ## What would the business lose without it? **Orders around the clock without the phone ringing, and the national accounts kept.** Half the order lines never touch the sales office. The customer types the order at ten at night from their own price list, so it is right the first time, and the reps spend the day selling rather than keying. When a customer wants to know where an order is, or wants last month's invoice again, they get it themselves. The EDI feed is the quieter dependency and the bigger one. For the national accounts EDI is a condition of supply: no feed, no listing. The feed takes their orders in whatever shape they send them, answers in the shape they demand, and gets the invoice to them in the form their system will pay. The mapping table, built up account by account over years, is what makes that work. ## Where it is starting to cost orders Systems like this stop being an asset the day a customer's audit looks at them. **The portal is what the supplier audit sees.** The national account's questionnaire asks about TLS, patching and the framework the site runs on. Classic ASP and Web Forms on an IIS server in the office answer badly, and so does a 2019 portal whose packages have not been touched since launch. The Cyber Essentials assessor asks the same questions of both. **The invoice feed has a deadline.** Electronic invoicing is due to become mandatory for business-to-business VAT invoices from April 2029, with the government's detailed timetable still to come. The national accounts will expect every invoice as structured data, and so will the trade accounts on the portal, so an invoice feed that sends a file to two accounts and a PDF to everyone else has to produce them for all. In a few businesses the oldest account's files still go over a dial-up or ISDN line, which the analogue switch-off on 31 January 2027 ends sooner. **Prices and stock on the portal are last night's.** The nightly copy from the order system means a customer orders at nine what sold out at eight, and the sales office phones to apologise. A price change made at ten is not on the portal until tomorrow. **Three agencies, three languages.** The last agency has moved on, and a change to the checkout means finding someone who knows Classic ASP, Web Forms and PHP at once. None of the three was laid out for a phone. ## What changes when it is modernised? **The same address and the same login, with live stock behind it and feeds the accounts will accept.** Each of these rests on something the system already does. **Live prices and stock.** The portal reads the order system's database as it stands, so the customer sees the stock the counter sees and today's price today. The apology calls stop. **One portal behind the same address.** The three codebases replaced one screen at a time, checkout first, behind the URL the customers have bookmarked. Their login, favourites and order history come with them because all of it is in the database. **A site the questionnaire can tick.** Nothing on it out of support, the server patched, the connection encrypted, and a login that passes the audit. The same answer serves Cyber Essentials. **EDI in the formats the accounts now ask for.** Each feed on the transport and in the format that account now requires, the code mapping carried over intact, and the failed-file folder replaced by a screen the sales office can see and act on. Invoices go out as structured data to every business account, well ahead of April 2029. **The portal on a phone.** A customer's buyer ordering from the van or the site, with the same basket. **Order status the customer can see.** Picked, on the van, delivered, on their own screen, including the orders the sales office is holding and why. The old pages are not switched off for any of this. Each new screen goes in beside them, on the same data, and the old one is removed when nothing links to it. ## Where would AI earn its keep on the portal and the feeds? **On the orders that do not look right, and the ones that still arrive as PDFs.** Every portal and EDI order already lands in one place with the account's history behind it, and that history is what AI works from: **Odd orders held before they are picked.** The hold rule catches an order over a set size. It does not catch a code that account has never bought, a case quantity keyed as single units, or a delivery to a depot the account closed last year. AI reads each portal and EDI order against that account's history and holds the ones that do not fit, with the reason beside them, for the sales office to release or query. Across several hundred portal orders a week and each morning's EDI batch, a held list of three or four orders a day at a minute or two each comes to under ten minutes to clear. Set against that, two or three wrong picks stopped in a week, at half an hour each for the return, the re-pick and the credit note, add up to an hour to an hour and a half. **PDF orders turned into portal orders.** The accounts that use neither EDI nor the portal have buyers who email a PDF purchase order in their own layout and codes, and someone in the sales office keys it. AI reads the PDF, matches the codes from what that account has bought before, and drafts the order in the portal for the sales office to confirm. At two to four dozen PDFs a week and ten minutes or so each to key and code, that works out at about four to eight hours, half a day to a day of the sales office's week. Not worth doing: AI-written product descriptions for a trade catalogue. The customers order by code and pack size, and a trade buyer scrolls past a paragraph to the price. The held list and the drafts both sit in the checkout and the order import, where a careless change does most harm, so AI waits until both can be changed and tried on a copy first. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows which would repay sooner on the portal and feeds as they are. ## The takeover, stage by stage The host and the feeds both have dates, so they go first. 1. **Stabilise.** Source for every codebase found, the agency's included, the site on a server that is patched and encrypted, a backup restored on purpose, and a test copy of the portal running against a copy of the database. This goes first because the supplier audit is already asking, and the host is where it looks first. 2. **The feeds brought up to date.** The translator made to speak the transports and formats the accounts now ask for, invoices included, the mapping table carried over, and a failure screen in place of the folder. The portal pages carry on as they are. 3. **Live prices and stock** in place of the nightly copy. This is the stage the customers notice. 4. **The checkout replaced**, then the account pages, then the catalogue, each behind the same address and each priced on its own. 5. **Order status and the phone layout.** 6. **Retire the old pages** when nothing links to them. The invoice download page is usually the last to go, because the customers have bookmarked it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a portal that means a few days with the sales office, the person who watches the EDI folder and the code, finding how the three sites share a login and what each account's feed demands, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a B2B ordering portal takeover What the assessment establishes for a portal and its EDI feeds, and why each item matters: | Check | Why it matters | |---|---| | Which pages are Classic ASP, which Web Forms and which PHP, and where is the source for each? | Three codebases, three build paths. A missing one changes the stage order. | | Where does the portal run, and what are the TLS, patching and framework versions? | This is what the supplier audit and Cyber Essentials ask. It decides whether the host moves first. | | How does the portal get prices and stock, and how often? | A nightly copy is the cause of the apology phone calls. A live read is the fix. | | Which EDI formats and transports do the national accounts use, and how does each invoice leave? | Electronic invoicing is due to become mandatory for business-to-business VAT invoices from April 2029, so every invoice route gets mapped. Where a dial-up or ISDN link survives, the January 2027 switch-off ends it. | | Where is the code mapping table, and who maintains it? | The mapping is the rule the national accounts feel. It has to survive. | | What happens to an EDI order that fails validation? | The folder and the one person who empties it are the specification for the failure screen. | | How does the customer login work across the three codebases? | The undocumented fix that shares a session is the first thing to break. | | Which orders are held for the sales office, and by what rule? | The hold rules protect the warehouse and the customer, and the new checkout has to keep them. | ## Questions Q: Our biggest customer wants us on a new EDI format. Can the old portal cope? A: The feed can, once it is brought up to date. The EDI translator is a separate piece from the customer-facing pages, so it can be taught the new format first, with the code mapping carried across, while the portal pages carry on as they are. That is usually the first stage after stabilising. Q: Does the portal have to go down while it is rebuilt? A: No. It keeps the same address and each page is replaced behind it, checkout first. Customers see the same site with fewer surprises, and the old pages stay until nothing links to them. Q: Will the customers have to learn a new site? A: No. Same login, same order history, same favourites, because all of that is in the database and the database stays. The layout changes where it has to for a phone, and the checkout gets shorter. Q: Can it show live stock instead of last night's? A: Yes. The nightly copy is replaced by a read of the order system's database as it stands, which is the stage most customers notice first. The traffic-light thresholds per product group stay as they are. Q: How soon is something live? A: The first stage is sized so something is working in about six weeks. For a portal that is usually the brought-up-to-date EDI feed or the live stock read, whichever has the nearer date on it. --- # The stock and purchasing system your warehouse picks from URL: https://www.solvewithsoftware.com/systems/wholesale-distribution/stock-purchasing-system Title: Stock and Purchasing Modernisation Description: A distributor's stock and purchasing system: reorder levels, goods-in, branch stock, where AI helps and what modernising brings. From £395 + VAT. Last reviewed: 2026-09-14 A stock and purchasing system is a distributor's count of what it has, where it is and what to buy next: every product at every location, the reorder levels, the supplier orders, the goods-in and the pick lists. Solve With Software takes over stock systems that grew inside a distributor over years, keeps them running, and modernises them in stages, so the buyer keeps the screens the business trusts while the warehouse gets scanners and the branch gets a figure it can believe. AI helps first with the supplier price lists and acknowledgements the buyer retypes, drafting the cost changes and new delivery dates for the buyer to accept. The assessment prices each stage before you commit. The Old Guard: An Access database from about 2004, with a .NET goods-in program and SQL Server added around 2010, on one Windows server in the warehouse office. The New Legacy: Built 2016 to 2022 by an agency in PHP or React, or in Power Apps, with an Ionic scanner app that the replacement handhelds no longer install. Where AI helps: AI reads supplier acknowledgements into draft dates: 50 to 200 a week at three minutes each works out to two and a half to ten hours of the buyer's week. ## What a stock and purchasing system does all day The buyer opens it before the kettle has boiled. The pickers work from what it prints until the last van has gone. A typical business running one of these has 20 to 80 staff, a main warehouse and one or two branches, 5,000 to 20,000 stock codes, 50 to 200 supplier purchase orders a week and somewhere between 300 and 1,000 pick lines a day. A few million pounds of stock sits in it. Whether it grew out of an Access database in 2004 or went live in a browser in 2019, the job is the same, and the warehouse leans on it in the same way. Every morning the suggested order list comes up, built from the reorder levels, the stock on hand and the orders already placed. The buyer corrects it from memory and raises the purchase orders, which go to the suppliers as PDFs by email. Goods-in books each delivery against its order, prints the bin labels and notes the shorts and the overs. The warehouse prints pick lists in bin order, raises the transfers for the branch and posts the adjustments. Once a month the valuation runs for the accountant, the dead-stock report runs for the MD, and twice a year the count sheets come out for the stock-take. The rules only this system knows: - Reorder levels are per location, and the branch's is a fraction of the warehouse's, set by the manager who opened it. - Some suppliers have a minimum order value or a carriage-paid threshold, and the suggested order rounds up to reach it when it is close. - Stock at the branch belongs to the warehouse until the transfer is booked, so the valuation counts it once. - Goods-in accepts an over-delivery of up to a tenth on some product groups and none on others. - A product that is out can be picked as a substitute, from a list of pairs the buyer maintains. ## The Old Guard: Access for the buyer, a .NET program at goods-in Started around 2004 as a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database for the reorder levels, written by the buyer of the day or a contractor. When the second location opened, around 2010, a small software house wrote the goods-in and picking screens as a .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) desktop program and moved the data into SQL Server (https://www.solvewithsoftware.com/modernise/sql-server). An IT contractor added the SSRS (https://www.solvewithsoftware.com/modernise/ssrs) reports for the monthly valuation a few years later. The Access screens are still what the buyer uses for suppliers and reorder levels. All of it runs on one Windows server in the warehouse office, with the goods-in program installed on the PC at the goods-in desk. The software house has since closed. The Access half can be edited by anyone brave enough and the .NET half by nobody, because nobody has its source. The branch works from a printout, the valuation still slows the pick, and the server under both is running out of support. ## The New Legacy: stock in a browser, from about 2019 The same stock system built between 2016 and 2022, usually by an agency or a freelancer as a web system in PHP (https://www.solvewithsoftware.com/modernise/php) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), or put together in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by an operations manager, with a scanner app for goods-in built in Ionic (https://www.solvewithsoftware.com/modernise/ionic). From the office it is a stock screen in a browser, a suggested order the buyer can open from home, and handhelds at goods-in that book against the purchase order. Since 2023 a few distributors have had a stock screen started in an AI app builder, which counted stock at one location and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the second. The handhelds are where it gives way. The scanner app was built for one model of device and never republished, so the replacements bought last year will not install it, and goods-in is back on paper for half the week. The reorder calculation lives in the agency's code, and a change to it once doubled every suggested quantity for a morning, after which the buyer stopped asking for changes. The agency's attention went to larger accounts, and the servers have not had an update since launch. On the paper days goods-in types up the morning's deliveries after lunch, and until then the stock screen is a morning behind. ## What does the warehouse get from it? **One buyer covering thousands of codes, and a stock figure the accountant will sign.** The suggested order is the reason the business has one buyer and not three. It does the arithmetic across every code every morning, so the buyer's day is spent on the exceptions: the supplier who is late again, the product that is suddenly moving, the carriage threshold that is nearly reached. Stock sits at the level the business decided, and the cash tied up in it is a known number rather than a guess. Goods booked against an order mean a supplier invoice can be matched, and disputed when it is wrong. Transfers are recorded, so stock does not vanish between the warehouse and the branch. The pick list comes out in bin order, which is why a new picker is useful on the first morning. And when the year end comes, the valuation is the system's figure, and the auditor accepts it. ## The places it no longer keeps up **Two locations, two truths.** The branch's stock figure lags the warehouse's by a transfer that was loaded but not yet booked, so the branch works from a printed list and phones to check. The stock-take finds the difference twice a year and nobody can say where it went. **The reorder levels are older than the buyer.** They were set by the person who opened the branch in 2011, carried across unchanged when any newer system went in, and adjusted by hand since. The buyer overrides the suggested order from memory every morning, and when the buyer is on holiday it goes out as suggested and the wrong things arrive. **The reports take all morning.** The valuation and the dead-stock report run on the same SQL Server 2016 that prints the pick lists, so when the valuation runs the pickers wait. SQL Server 2016 updates ended in July 2026, and the Windows Server 2016 under it ends in January 2027. **Nobody has the source for the goods-in program.** The software house that wrote it closed, and the last install file is on the goods-in PC. A barcode scanner cannot be added because nothing in the program can be changed, and if that PC fails, goods-in stops with it. ## What does modernising bring the buyer and the warehouse? **A stock figure that is right at every location, and reports that never slow the pick.** Each of these grows out of something the system already does. **One stock figure everywhere.** Goods-in, put-away, the pick and the transfer written to one record as they happen, from a scanner. The branch stops phoning, and the stock-take confirms the figure rather than discovering it. **Reorder levels from what sold.** Levels recalculated from the sales history and the real lead times, with the buyer's overrides recorded as data. The suggested order is right when the buyer is away. **Reports off the picking server.** The valuation and the dead-stock report as a dashboard against a reporting copy, in seconds, while the SSRS reports keep running until each has been replaced. Picking never waits for a report again. **Purchase orders that come back acknowledged.** Orders sent electronically, acknowledgements read back in, and the late-supplier list live on a screen instead of monthly on paper. **Goods-in on a scanner.** The goods-in screen on a handheld, booking against the order with the over-delivery rules intact. The goods-in PC stops being the one PC. **Stock-take without count sheets.** Counted on the handheld, differences posted the same day, and a rolling count through the year in place of the twice-yearly shutdown. The old screens are not switched off for any of this, whether they are Access and a .NET program or the agency's site. Each piece is added beside them, on the same stock records. ## Where does AI help a buyer with thousands of codes? **In supplier paperwork, questions the order history can answer, and slow movers nobody has time to find.** The buying decisions stay with the buyer. AI works on what the system already holds or receives: **Price lists and acknowledgements read in.** Suppliers send price lists as PDFs or spreadsheets in their own layouts, and acknowledgements as emails with a changed delivery date halfway down. AI reads each one, matches the supplier's codes to the stock codes, and drafts the cost changes and the new dates against the open orders for the buyer to accept or correct. At 50 to 200 purchase orders a week, and three minutes or so to read and re-date each acknowledgement, that works out to about two and a half to ten hours of the buyer's week, before the price lists are counted. **Supplier questions answered from the orders.** What did we last pay for this code, and which supplier has been late with it most this year? AI answers in a sentence from the purchase orders and goods-in bookings through a read-only link, and lists the orders it used for checking. Asked four or five times a day, at five or six minutes of searching each, that adds up to twenty minutes to half an hour a day the buyer keeps. **Slow movers found before the valuation.** The dead-stock report lists what has already stopped selling. AI reads the sales history across every code and location, picks out the codes whose demand is fading, and drafts a clear-out list naming the branch that could use each one. If across 5,000 to 20,000 codes that list runs to three or four dozen lines, at about twenty seconds a line to accept or strike, the review comes to about a quarter of an hour where the report took a morning with a highlighter. Not worth doing: a chat interface for the pickers. A scanner with three buttons beats it on a cold warehouse floor, and nobody in gloves types a question. The drafts land on open orders and live stock records, so they wait until the stock system can be changed without stopping the pick. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows where on this system they would repay first. ## Stage by stage, with the old system as the fallback The first move takes the two dated risks out of the room. 1. **Stabilise.** The database on a version that is still supported, on a server that is still supported, a backup restored on purpose, the .NET program's source (or the agency's code) found or its behaviour documented screen by screen, and a test copy of the whole thing. This goes first because a goods-in program with no source is what stops the warehouse, and nothing should be built on a server that ends in January 2027. 2. **Goods-in and transfers on a scanner.** The goods-in screen on a handheld, writing to the same stock records the Access screens read. Small, live in weeks, and the end of the two truths. 3. **Reorder levels from history.** The calculation rebuilt from sales and lead times, the buyer's overrides kept as data, the Access suggested-order screen reading the result until the new one replaces it. 4. **Reports off a reporting copy.** The valuation as a dashboard, the SSRS reports retired one at a time as each has a replacement the accountant accepts. 5. **Electronic purchase orders, picking on the scanner, the rolling stock-take.** Each a stage, each priced on its own. 6. **Retire Access and the .NET program**, or the agency's site, when nothing still opens them. The supplier screen in Access is usually the last to go, because the buyer trusts it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a stock system that means a few days with the buyer, the goods-in desk and the database, finding where the levels and the rules live and how far the figures have drifted from the shelves, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a stock and purchasing system takeover What the assessment establishes for a stock system, and why each item matters: | Check | Why it matters | |---|---| | Which parts are Access, which are the .NET program, and is there source for each? | The goods-in program with no source is the first risk. Access usually carries its own. | | Where do the reorder levels live, and how does the buyer override them? | The overrides in the buyer's head are the specification for the new calculation. | | How is branch stock recorded, and at what moment does a transfer move it? | The gap between loading and booking is where the two truths come from. | | Which SQL Server and Windows Server versions, and what else runs on that box? | SQL Server 2016 updates ended in July 2026 and Windows Server 2016 ends in January 2027. Reports competing with picking says the server moves first. | | Which SSRS reports does the business run on, and which one does the auditor see? | The valuation report carries the costing method. It is a specification. | | How are purchase orders sent, and what happens to the acknowledgement? | Sent as a PDF and acknowledged by nobody is the norm, and the late-supplier list depends on it. | | What does the stock-take find, and how is the difference posted? | The size of the adjustment says how far the figures have drifted from the shelves. | | Where does the sales order system meet this one? | The pick list is the join. Whether the two share a database decides the stage order. | ## Questions Q: Our stock figures never agree between the warehouse and the branch. Will modernising fix that? A: That is usually the first thing it fixes. The gap comes from movements booked later than they happened, and a scanner at goods-in, on the pick and on the transfer closes it. The stock-take then confirms the figure rather than correcting it. Q: Half of it is Access and half is a .NET program nobody has the source for. Can it be modernised as one system? A: Yes, because they share the database, and the database is what gets modernised first. The .NET program is the risk, so its screens are the first to be replaced, on a handheld scanner, against the same records. The Access screens keep working against the same data until each has a reason to go. Q: Can we keep our reorder levels and the buyer's exceptions? A: Yes. The levels and the exceptions are found first and kept as data. The change is that the buyer's overrides are recorded, so the suggested order is right when the buyer is away, and the levels can be recalculated from sales when the buyer wants them to be. Q: Will the warehouse have to stop for it? A: No. Each new piece is run beside the old one, on the same stock records, and the pickers switch when the scanner is quicker than the printed list. The database goes onto its supported version outside picking hours, rehearsed on a copy first. Q: When is something live? A: The first stage is sized so something is working in about six weeks. For a stock system that is usually goods-in on a scanner, booking against the purchase orders the buyer already raises. --- # The sales order system behind your trade counter URL: https://www.solvewithsoftware.com/systems/wholesale-distribution/trade-counter-order-system Title: Trade Counter System Modernisation Description: A merchant's homegrown trade counter and sales order system: price tiers, the Sage link, where AI helps and what modernising brings. From £395 + VAT. Last reviewed: 2026-09-14 A trade counter and sales order system is a merchant's price book with a till attached: it knows what every account pays, takes the order at the counter, on the phone or by email, and turns it into a pick note, a delivery note and an invoice. Solve With Software takes over the homegrown ones, and packages customised past the point of upgrade, keeps them running and modernises them in stages, so the counter keeps the screen it knows while the prices move into the office's hands. AI helps first with the emailed order lists the sales office keys by hand, drafting each order at the customer's own prices for someone to check. The assessment prices each stage before you commit. The Old Guard: Written 2003 to 2010 in VB6 by a contractor or a small software house, on SQL Server, and still running on the back-office server and the counter PCs. The New Legacy: Built 2016 to 2022 by a web agency in PHP or React, or on a low-code builder, with the contract price rules buried in the agency's code. Where AI helps: AI drafts emailed lists into orders at each account's prices: a third of 150 to 600 lines at about forty seconds each comes to about half an hour to two hours. ## The system behind the trade counter It is called Sales, or Orders, or the name of the man who wrote it, and it is open on every PC in the building by seven. A typical business running one of these has 15 to 60 staff across one or two branches, a counter that serves a queue of vans before eight, and somewhere between 150 and 600 order lines a day across the counter, the phone and the reps' emails. The ledger runs to a few hundred trade accounts, twenty of which matter more than the rest put together. Written in 2006 or in 2019, it does the same job. Most builders', plumbers' and electrical merchants run a bought trade package. This page is about the counter system written for one merchant, or a package whose pricing was customised past the point of upgrade. At the counter it finds the customer, takes the lines by code or by a description close enough, prices each one, and prints the invoice or the delivery note. A card payment is keyed a second time, into the standalone card machine beside the till. In the sales office it takes phone orders and quotes, holds short lines on back order, sends pick notes to the warehouse and runs the invoices at five. At month end it builds the Sage file, and on Monday the MD reads the margin-by-customer report. The rules it holds are the ones the big accounts were won on: - A contract price beats the tier price, which beats list, except for a promotion, which beats everything unless the account is on a fixed contract. - Quantity breaks are per pack for some product groups and per unit for others, and the counter rounds up to full packs where the supplier will not split. - Back orders release to the three largest accounts first, then oldest order first. - Cash and account sales post to different Sage nominals, and a handful of customers get one invoice a month instead of one per delivery. None of it is written down anywhere else. ## The Old Guard: the VB6 program on the counter since 2006 Written between 2003 and 2010 in Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) by a contractor who had done one for another merchant, or by a small software house that has since folded, and extended every year after: a price tier screen, back orders, the second branch. The data sits in SQL Server (https://www.solvewithsoftware.com/modernise/sql-server), Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports) prints the invoices, delivery notes and statements, and the export to Sage (https://www.solvewithsoftware.com/modernise/sage-integrations) has been rewritten twice as Sage changed. It runs on a server in the back office and on the counter PCs. Around 2019 the contractor's number stopped connecting. The firm that looks after the network swaps PCs and printers but has never opened the program, so the pricing rules inside it are as they were the last time anyone edited the code. It cannot be opened from the yard or send an email, and a new counter PC is a gamble. ## The New Legacy: the 2018 order screen from a web agency The same system built between 2016 and 2022 by a web agency or a freelancer, as a web system in PHP (https://www.solvewithsoftware.com/modernise/php) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), or by someone in the office on a low-code builder such as Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps). It opens in a browser on the counter PC, the reps log in from the car, and the invoices come out as PDFs. Since 2023 a few merchants have had a counter screen started in an AI app builder instead, which priced a basket at list well enough and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the first contract price with an exception. The price book is what pins it. The agency stored tiers and list prices as data, but the precedence between contract, promotion and fixed-contract prices went into its code as special cases, pack rounding too, so a new deal for a big account still needs a developer. The Sage link was the last part promised and never arrived. In 2023 a pricing change rounded some packs down for a week before the counter spotted it, and the office has asked for nothing since. The agency has other clients now, and the hosting renews on an invoice nobody in the office recognises. ## Why does the business depend on it? **Every order priced right, whoever takes it, and a counter that clears the morning queue.** The price book is the business. A few hundred accounts on a dozen tiers, contract prices for the ones that matter, breaks that differ by product group, and the system applies all of it without anyone looking anything up. A new starter on the counter charges what the person who negotiated the deal would, and that is what keeps the big accounts. Speed is the other half. The queue at half past seven gets served because the customer's history and the product search are a keystroke away, and the invoice is on the counter before the van has turned round. Back orders are tracked rather than promised and forgotten. The margin report tells the sales office when a rep has given too much away, and month end goes to Sage in one file, so the sales ledger and the accounts agree. ## Where it has started to strain Systems like this do not break. The office grows a set of habits around them. **The price book is half in the code.** Tiers and contract prices are in tables, but the precedence between them, the pack rounding and the odd exception for one account were written into the code. A price change for a big account waits for a developer who is no longer there, and the sales office keeps a spreadsheet of the prices it gets wrong. **The counter has two deadlines.** Windows 10 support ended in October 2025, and when a counter PC moves to Windows 11 the Crystal print path tends to fail with it. The card machine beside the till is keyed by hand from the screen, and terminals still on a phone line stop taking payments when the analogue network switches off on 31 January 2027. **Month end runs through one person.** In the older system the Sage export was built for the 2012 version, and each upgrade has been put off since the last one broke it. In the newer one the Sage link never arrived, so the file is built in a spreadsheet. Either way, one person in accounts knows the hand corrections made before the import. **The customers expect to be told.** The big accounts want an order confirmation and a back-order update by email, and the reps want stock and prices from a customer's yard. The system prints. So the sales office spends its afternoons emailing PDFs it has printed to itself. ## What does modernising the counter system bring? **The same order screen, with the price book in the office's hands and the paperwork sending itself.** **The price book as data.** Every tier, contract price, break and exception comes out of the code into screens the sales office owns, with a record of who changed what. A new price for a big account takes minutes, and the spreadsheet of wrong prices goes. **The counter in a browser.** The order screen opened in a browser, on the same data, on any PC, on a tablet in the yard, or from home. The invoice prints as a PDF, so the Windows version on the counter stops mattering. **Card sales keyed once.** The order total goes to the card terminal from the screen and the payment comes back against the invoice, so the till and the ledger agree at close, on a terminal that no longer needs the phone line. **Confirmations that send themselves.** An email when the order is saved, with the customer's PO reference and the delivery day, and a note when a back order releases. **Sage posted daily.** The hand corrections become rules in the export, so the link runs each evening and month end becomes a check rather than a job. The next Sage upgrade gets tested on a copy first. **Reps ordering from the yard.** Live stock across both branches and the customer's own price, on a phone, writing into the same order file the counter uses. Neither generation of the old program is switched off for any of this. Each piece is added beside it, on the same data, and the counter moves when the new screen is faster. ## Where would AI save the sales office time? **In emailed order lists, the questions no report answers, and prices that slip below margin.** The pricing stays with the rules. AI does the reading and the looking up: **Emailed lists turned into orders.** An electrician's list in an email, a photographed job sheet, a buyer's PDF with half the codes missing: someone reads each one, hunts the codes and keys the lines. AI matches each line to a code from what that customer has bought before and drafts the order at their own prices, leaving the unmatched lines for a person. If a third of the day's 150 to 600 lines come in this way, that is 50 to 200 lines, and at about forty seconds a line to find the code and key it, the keying works out at about half an hour to two hours each morning. **Questions no report was written for.** A rep wants to know what an account paid for a drum of cable last time, and which plumbers who used to buy a boiler range have not ordered it since spring. AI answers in plain words from the order lines, which it can read but never change, and lists the invoices behind the answer for checking before a quote. A question that took a quarter of an hour in the order history takes a minute, so three or four of them a day comes to about three quarters of an hour to an hour back. **Lines below margin caught before five.** A generous discount or a mistyped price shows up on the Monday report, after the invoice has gone. AI reads the day's lines against what each account usually pays and flags the ones out of pattern. If the day's 150 to 600 lines throw up four or five flags, at a minute or two each to check, that adds up to ten minutes at most before the invoice run, in place of a Monday morning with the report. Not worth doing: AI-set prices for trade accounts. The tiers exist because customers negotiated them and expect them to hold, and a price that moves on its own loses one of the twenty accounts that matter. All three write into the order file, so none starts until that file can be changed without the counter feeling it. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows which would repay soonest on the system as it is. ## How we would stage it Safe to change first, then the price book, the part that changes most. 1. **Stabilise.** The VB6 source, or the agency's code, found and matched to the running program, the database on a version that is still supported, a backup restored on purpose, and a test copy with a copy of Sage beside it. This goes first because the price rules cannot be moved out of code that cannot be changed safely. 2. **The price book out of the code.** The precedence, the breaks and the exceptions written down with the sales office, put into tables and given a screen, which the old order form then reads. 3. **Confirmations and back-order emails.** Small, built on the orders already in the system, and the first thing the customers feel. 4. **The counter screen in a browser**, run beside the old form until the counter staff choose it, then the sales office screens. 5. **Sage posting daily, card sales keyed once, the reps' phone view.** Each a stage, each priced on its own, with the invoice run ready for electronic invoicing before April 2029. 6. **Retire the old program**, VB6 or the agency's site, when nothing still opens it. The last thing to go is usually the invoice layout, because the customers are used to it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a sales order system that means a few days with the counter, the sales office and the code, finding where every pricing rule lives and what the Sage export does by hand, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a trade counter system takeover What the assessment establishes for a sales order system, and why each item matters: | Check | Why it matters | |---|---| | Where does the price precedence live: in tables, in the VB6, or both? | Rules in code mean every price change is a developer change. The split decides what the first stage is. | | Is the VB6 source available, and does it build to the program the counter is running? | Without it the pricing rules are read from behaviour, which takes longer and finds fewer of the exceptions. | | Which SQL Server version, and where is it running? | SQL Server 2016 updates ended in July 2026. The database goes onto a supported version before anything is built on it. | | How does the counter print, and what does the Crystal invoice layout carry? | The layout carries rules of its own: the VAT note, the cash-sale wording, the customer's PO reference. The print path is the commonest thing to break on a new PC. | | What does the Sage export contain, and what is corrected by hand before the import? | The corrections are the specification for the rebuilt link. | | How are back orders held, and in what order do they release? | The release rules are the ones the big accounts feel. They have to survive. | | Which accounts have contract prices, and when was each last reviewed? | Contract prices outlive the contracts. The assessment finds the ones nobody has looked at in years. | | Can the invoice run send each account invoice as structured data? | Electronic invoicing is due to become mandatory for business-to-business VAT invoices from April 2029. A printed or PDF invoice is not structured data, and most of what this system invoices goes to VAT-registered trade accounts. | ## Questions Q: Can we keep our price tiers and the special prices for the big accounts? A: Yes, and they are the first thing found. They are the most valuable part of the system and the part a rewrite loses. They come out of the code, get written down with the sales office, and go into screens the office maintains. Q: The program is VB6 and the counter PCs are old. Does it have to be rewritten? A: No. The data underneath is usually sound and stays where it is. The VB6 screens keep running while browser screens are added beside them, and once the counter is on the new screen the Windows version on that PC stops mattering. Q: Will it still post to Sage? A: Yes. The export is the first thing tested, on a copy, before anything else moves. Then it is rebuilt to post daily, with the corrections accounts makes by hand turned into rules, so month end is a check rather than a job. Q: Can our reps take orders from a customer's yard? A: Yes. A phone view of stock and the customer's own prices, writing into the same order file the counter uses, is a small stage on its own once the price book is in data. --- # The rounds system and handheld app that run your vans URL: https://www.solvewithsoftware.com/systems/wholesale-distribution/van-sales-delivery-system Title: Van Sales System Modernisation Description: A van sales and delivery rounds system: round planning, van stock, the drivers' app, where AI helps and what modernising brings. From £395 + VAT. Last reviewed: 2026-09-14 A van sales and delivery system is the depot's memory of every round: which customer takes what on which day, what went out on the van, what was dropped, sold, returned and signed for, and what to invoice tonight. Solve With Software takes over rounds systems and the handheld apps that depend on them, keeps them running, and modernises them in stages, so the drivers keep the round they know while the office sees the drops as they happen. AI helps first with the loading sheet, drafting the extras each van should carry from what each customer takes on that weekday. The assessment prices each stage before you commit. The Old Guard: A .NET office program from about 2008 by a contractor, on SQL Server, with a 2013 Cordova app on rugged Android handhelds syncing to the office server. The New Legacy: Built 2016 to 2022 by an agency, the office side in React or Node and the drivers' app in React Native or Ionic on ordinary phones. Where AI helps: AI drafts the extra van stock for each round: 6 to 20 rounds at two minutes of adjusting each works out to twelve to forty minutes of the planner's afternoon. ## Rounds, vans and the drivers' handheld Two halves. A program in the office that builds the rounds, and an app in the cab that works them. A typical business running one of these has 10 to 40 staff and 6 to 20 vans, each van making 30 to 60 drops a day on fixed weekly rounds, a few thousand delivery lines a day between them, with cash or a card taken at the door from some customers. Food and drink, catering supplies, bakery and dairy, cleaning and industrial consumables: the trades where the van is the shop. Whether it is a desktop program from 2008 or a browser system from 2019, the job is the same. In the office it holds each customer's standing order for each weekday, builds the round in the driver's sequence, prints the loading sheet and allocates the van stock. On the handheld the driver sees the drops in order, records what was delivered against what was ordered, sells extras from the van, takes the returns and the empties, captures a signature, prints a delivery note on the belt printer and records the cash. Back at the depot the van stock is counted, the cash sheet is filled in, the handheld syncs, and the invoices and credit notes raise. The week ends with the statements and the accounts export. The rules that live in it and nowhere else: - The loading sheet is the standing orders plus the phoned orders minus the customers on holiday. - Van stock sells at the account price to account customers and at van price to cash customers, with a discount limit per driver. - Returns credit at the delivered price if the driver marks them on the day, and at a lower rate afterwards. - On chilled, dairy and bakery rounds a drop will not close until the temperature at handover is recorded, and a reading over the limit for that product goes to the office before the invoice raises. - A drop is not invoiced until the signature is in, and a drop without one is a phone call the next morning. ## The Old Guard: a 2008 office program and a Cordova handheld The office program was written around 2008 in .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) by a contractor, with the data in SQL Server (https://www.solvewithsoftware.com/modernise/sql-server). The handheld app began on Windows Mobile devices and was replaced around 2013 by a PhoneGap or Cordova (https://www.solvewithsoftware.com/modernise/phonegap-cordova) app on rugged Android handhelds, written by a small agency, or in a few fleets by a native Android app (https://www.solvewithsoftware.com/modernise/native-mobile-apps) from the same contractor. A Windows service on the office server takes the sync, from the vans where there is signal and over the depot Wi-Fi at the end of the day. The program runs on that server and the planner's PC, and the loading sheets come out of the printer by the loading bay. The contractor has moved on, and the agency took the app's build tooling with it. The office program keeps working as long as it is left alone, the handhelds as long as nobody updates them, and the sync service is the part no one in the depot can explain. ## The New Legacy: rounds in a browser and an app on the drivers' phones The same rounds system built between 2016 and 2022 by an agency or a freelancer: the office side as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), and the drivers' app in React Native (https://www.solvewithsoftware.com/modernise/react-native) or Ionic (https://www.solvewithsoftware.com/modernise/ionic) on ordinary phones, or all of it in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps). The planner builds the rounds in a browser, drops sync whenever there is signal, and signatures arrive as pictures. Since 2023 a few depots have tried a drivers' app from an AI app builder, which showed the drop list on a phone and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) on the first round through a black spot. The app stores are what strand it. Since 28 April 2026 an iPhone build has to be made with Xcode 26, and since 31 August 2026 an Android update has to target Android 16. The agency's project meets neither, so no fix can go out, the store account is in the agency's name anyway, and the phone a new driver brings will not install the old version. A change to the returns credit once stopped the offline queue sending for a day, and no version has gone out since. The office side runs on the versions it launched with. ## What does it let a small depot do? **Run twenty rounds a day from one office, and invoice every drop the day it was made.** The loading sheet is the quiet part. Because the standing orders are in the system, the van goes out with what the round needs rather than what the driver remembers, and the extras it sells off the back are priced right without a call to the office. A new driver can run a round in the first week, because the handheld knows the sequence and what each customer takes. The signature is the loud part. Every delivery carries one, so a dispute is settled with a picture rather than an argument. And because the sync feeds the invoice run, every drop is billed the day the van gets back, the returns are credited at the right rate, and the cash reconciles to what was sold. ## Where the handheld has become the problem Systems like this are held back by the piece in the cab, and by the piece in the server cupboard that talks to it. **The app will not install on a new phone.** The Cordova app was built for the Android of 2013 and the tooling to rebuild it went with the agency, while the newer phone app has fallen out of the store for want of an update. Either way the depot keeps a drawer of old devices and a charger for each. When the last one dies, the round goes back to paper. **Nothing is invoiced until the vans are back.** The app syncs on the depot Wi-Fi, so the office sees the drops at six and the invoices run at seven. A customer who phones at two to ask whether the van has been gets "I'll ask the driver". **The sync server has a date on it.** The Windows service runs on Windows Server 2016, which ends in January 2027. Moving it means rebuilding the handhelds' connection to it, and nobody left in the building knows how the handhelds find the server. **The cash sheet and the van count are on paper.** The count back and the cash are written on a sheet at the depot and typed into the office program afterwards. The difference between what was loaded, sold and returned is found on Friday, by which time the driver has forgotten Tuesday. ## What does modernising it give the drivers and the office? **The same round on a phone that can be replaced, with the office watching it happen.** Each of these comes from something the system already does. **The app on any phone.** An app that installs on any current phone and can be kept up to date, laid out from the old one so the drop list is where the drivers expect it. The drawer of old handhelds retires. **Drops in the office as they happen.** Each drop posts over the mobile network where there is signal and queues where there is not. The office answers "has the van been?" from the screen and invoices during the day rather than at seven. **Van stock and cash that reconcile themselves.** Loaded, sold, returned and counted back on the handheld. The Friday difference becomes a same-day one, with the driver still in the building. **The sync on a supported server.** The link between the handhelds and the office on a server that is still supported, one that can be backed up and watched, and that the handhelds can find wherever it sits. The January 2027 date stops mattering. **The customer told the van is close.** A text when the driver marks the previous drop done, so the goods-in door is open when the van pulls up. None of this switches the old app off, whichever generation it is. The new app writes to the same database, and the vans move across one at a time. ## Is there a job for AI on a delivery round? **Yes: in what goes on the van, and in the paper that comes back off it.** The round itself stays the driver's. AI works on the data the rounds system already collects, drop by drop, in two places: **A loading suggestion for each round.** The loading sheet covers the standing orders, but the extras sold off the back are the driver's guess and the planner's memory. AI reads what each customer has taken on that weekday over recent months, extras included, and drafts the extra van stock for the loader to check against the sheet. The van goes out with what it will sell rather than what it will bring back. At two minutes of adjusting per round across 6 to 20 vans, that works out to twelve to forty minutes of the planner's afternoon. **Doorstep notes into standing orders.** A customer hands the driver a scribbled note, or the driver photographs an order form on the counter: two more cases from next week, nothing over the holidays. Today the note travels in the cab and someone in the office types it in, if it survives the trip. AI reads the photo into a change to that customer's standing order for the office to confirm, so the next loading sheet is right. Three notes a week coming back on each of 6 to 20 vans makes 18 to 60 notes, and at four minutes each to type and confirm by phone, that adds up to about an hour and a quarter to four hours of the office's week. Not worth doing: re-sequencing the rounds by AI. The customers expect the van at the same time each week, the goods-in door is open for it, and the driver knows the sequence better than any model. Both write into the standing orders, so AI waits until the new app is on the vans and the rounds data can be changed without putting tomorrow's loading at risk. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows where it would repay first on the rounds as they run now. ## How the stages run The app goes first, because it is the piece that can fail without warning. 1. **Stabilise.** Source for the office program and the app found, including the agency's code and the app's store account, or the app's behaviour documented screen by screen; the database on a version that is still supported; a backup restored on purpose; a test copy; and the sync service understood well enough to move. This goes first because the handhelds are a countdown and the server they talk to has a date. 2. **The drivers' app, on two vans.** A new app on the same data, laid out from the old one, and run on two rounds with the old handhelds on the rest. The drivers on the other vans ask for it or they do not, and either answer is useful. 3. **Live sync and same-day invoicing**, once every van is on the new app and the old sync service has nothing left to do. 4. **Van stock and cash on the handheld**, so the paper sheet goes and the count is done with the driver present. 5. **Customer texts and the loading suggestions.** Each a stage, each priced on its own. 6. **Retire the old handhelds and the sync service**, or the old app and the agency's site, when nothing depends on them. The office rounds screen is usually the last to go, because the planner knows it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a rounds system that means a few days with the planner, a driver or two and the code, finding how the handhelds talk to the office and which rules the invoice run depends on, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a van sales and delivery system takeover What the assessment establishes for a rounds system, and why each item matters: | Check | Why it matters | |---|---| | Is the app's source available, and can it still be built? | A Cordova app that cannot be rebuilt is a countdown. The build tooling matters as much as the code. | | Which Android version, which handhelds, and how many spares are in the drawer? | Says how long the business has before the first stage must be live. | | How does the handheld talk to the office, and what happens when it has no signal? | The sync service is the join, and the new app has to survive a round through a black spot. | | Where do the standing orders live, and who changes them? | They are the loading sheet. The holiday rule and the extras live in them. | | How is van stock loaded, counted back and adjusted? | The gap between the sheet and the system is the Friday difference. | | What does the invoice run do with a drop that has no signature? | The exception the customers feel, and the rule that has to survive. | | Which Windows Server and SQL Server versions run the sync and the database? | Windows Server 2016 ends in January 2027. The service has to move, and the handhelds have to follow it. | | What does the belt printer print, and which customers need it? | Decides whether the new app needs a printer or an email. | ## Questions Q: Our handheld app only works on the old phones. Do we have to start again? A: No. The data behind it, the rounds, the standing orders and the prices, is in the database and stays there. A new app goes on that data, one that installs on any current phone, and the old handhelds keep running on the vans that have not switched yet. Q: Can the drivers keep the same sequence and the same screens? A: Yes. The round sequence is the driver's and it stays in the data. The new app is laid out from the old one, drop list first, so a driver who has used the handheld for years is not learning a new job. Q: Will the office see the drops during the day? A: Yes, once every van is on the new app. Each drop posts as it happens where there is signal and queues where there is not, so the office sees the round filling in and can invoice before the van is back. Q: What happens to the rounds while the app is replaced? A: Nothing. The new app goes on two vans first, writing to the same database as the old handhelds, and the rest follow when those drivers ask for it. If a new handheld fails on a round, the old one still works. Q: How long before something is live? A: The first stage is sized so something is working in about six weeks. For a rounds system that is usually the new app on the first two vans, which tells everybody whether we understood the round. --- # Systems that run field service businesses URL: https://www.solvewithsoftware.com/systems/field-services Title: Field Service Systems Modernisation Description: The systems that run field service firms, old and new, job sheets to the engineers' app, and where AI helps on each. From £395 + VAT. Last reviewed: 2026-09-14 Field service businesses run on a system that was built for one office and its vans: the jobs and the engineers' diaries, the contracts and certificates, the app in the engineer's hand, or the yard's bookings and weighbridge. Solve With Software takes those systems over and modernises them in stages, so the office keeps the screen it knows while the engineers, the customers and the accounts get connected to it, and AI reads the job requests, old certificates and tip invoices that someone keys in today. The pages below describe the kinds of system we see, in both their generations, and what modernising each brings. ## Where the vans go Heating, electrical, fire and refrigeration engineers, compliance contractors working for housing providers, schools and care homes, and skip and waste yards run systems like these in every part of the UK. Nearer home they work out of Colchester, Chelmsford and Ipswich and cover Essex and Suffolk by van, from Southend up to the Suffolk coast. Each has a system at the centre of the office that was built for the way that one business works, and each has the same question about it: how do we move it forward without stopping the vans? Colchester is home, and the vans can be based anywhere in the UK. The work is remote wherever the office is, and on-site across Essex, Suffolk and London when the system needs it. The regional page (https://www.solvewithsoftware.com/essex-suffolk-london) says how the local side works. ## The same office system, built twice **The Old Guard** was written between the early 2000s and about 2013. The job diary (https://www.solvewithsoftware.com/systems/field-services/job-sheet-engineer-scheduling-system) grew from an Access database into a .NET Windows program; the contracts and certificates system (https://www.solvewithsoftware.com/systems/field-services/planned-maintenance-certificates-system) is Access with Crystal certificates and a workbook of reminders; the skip yard (https://www.solvewithsoftware.com/systems/field-services/skip-hire-waste-collection-system) runs a Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) booking screen wired to the weighbridge. The first engineers' apps (https://www.solvewithsoftware.com/systems/field-services/engineer-mobile-app) came a little later, wrapped in PhoneGap or Cordova (https://www.solvewithsoftware.com/modernise/phonegap-cordova) between 2012 and 2017. **The New Legacy** is the same system built from about 2016 by an agency or a freelancer, as a browser diary with a React Native app, or in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or Zoho Creator by an office manager who wanted the paper gone. Since 2023 some firms have tried again with an AI builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) before offline working or the Sage link. Many service firms run a bought job management app for the engineers and keep a homegrown system for the contracts, the certificates or the yard. The join between the two is where these systems usually get stuck. ## What modernising them gives the office Three things, whichever system it is. The engineer's phone gets connected to it: the job sheet, the certificate, the transfer note and the customer's signature arrive in the office while the van is still on site, so the invoice goes the same day and the paper stops. The office gets one record instead of two: the due list without the spreadsheet beside it, the booking without being keyed twice, the app and the office system free to change without waiting on each other. And the questions that used to take a week get answered from a screen: the housing provider's audit, the insurer's questionnaire, the margin on last week's skips. Once the system is safe to change, AI takes the reading and the matching off the desk too: the job request drafted from the facilities manager's email, the old certificate read into the asset register, the tip's invoice matched to its weighbridge tickets. Each system page works out the time that gives back at its own job volumes. None of it needs the old program switched off. Each piece goes in beside it, on the same data, and the office stops opening the old screen when the new one is better. ## Questions Q: Do the vans stop while the system is modernised? A: No. The old system keeps running and each new piece goes in beside it on the same data, so the diary, the due list or the booking screen stays open throughout. The office switches to a new screen when it is better than the old one, and the old program is retired when nothing depends on it. Q: Our system holds rules nobody has written down. Do they survive? A: They are the first thing the assessment looks for. The rate card, the certificate anniversary rule, the council permit notice days and the customers whose PO number is enough are found in the code, the reports and the spreadsheet with the people who use them, and written down. The old code stays as the reference until the new screens match it, and the history moves across as it is. Q: Is there anything AI could do for a system like ours? A: Yes, once the system is safe to change, and in the paperwork rather than the scheduling. On systems like these it reads what already arrives in writing or in a photo, the job request email, the engineer's notes, the data plate on a boiler, the tip's invoice, and drafts the job, the report or the match for someone to check rather than type. It also answers the office's questions from the records, such as which sites on a contract still have a remedial outstanding. It comes after the first stage, because nothing new can be added safely to a system nobody can change, and the assessment maps where it would pay back on the system as it stands. Q: What does it cost, and how soon is there something to show for it? A: The assessment is from £395 + VAT, with an exact price before you commit. It produces a report with costed options and a fixed price for each, and the first stage usually has something working within about six weeks, with each stage after that priced before you commit to it. The report is yours. Take it to us, another developer, or nobody. Q: Our system is not one of the four on this page. Is it the same kind of work? A: Usually. The four pages describe the shapes that come up most often in field service businesses, and the system in the office is often a mix of them: a job diary with a certificates module, or a yard system with a drivers' app added later. The free consultation is where that gets worked out, and the assessment is sized on what is there. --- # The app your engineers work from URL: https://www.solvewithsoftware.com/systems/field-services/engineer-mobile-app Title: Engineer Mobile App Modernisation Description: The app a service business's engineers work from, where AI helps on site, and how a stuck one gets shipping again and modernised. From £395 + VAT. Last reviewed: 2026-09-14 The engineers' mobile app is the half of a field service system that leaves the building: the day's jobs, the photos, the parts and the customer's signature, back in the office before the van has moved. Solve With Software takes over apps like this when the agency that built them has gone and the stores will no longer accept a build, gets them shipping again in the business's own accounts, and then modernises them in stages against the same office system. Once it builds, AI helps first at the data plate, reading the make, model and serial from a photo so the engineer confirms them instead of typing. The assessment prices each stage before you commit. The Old Guard: Built between 2010 and 2013 by an agency, as web code wrapped in PhoneGap, Cordova or Ionic or as a native pair, on the phones already in the vans. The New Legacy: Built between 2018 and 2022 by an agency in React Native on its own Node API, or in Power Apps or FlutterFlow, with the store accounts in its name. Where AI helps: Data plates read from a photo: one job in three of 60 to 250 a day, at a couple of minutes each, works out at about 40 minutes to three hours of typing. ## The app in the engineer's hand The office system stays on the desk. This is the part that goes out in the van. A typical business running one of these has 10 to 40 engineers on the app, one office, and 60 to 250 jobs a day passing through it. It is the reason the office stopped keying in paper sheets, and it talks to a link on the office system that somebody wrote alongside it. Whichever generation of app is in the engineers' pockets, the work it does in the van is the same. In the engineer's words, it shows the day's list, opens a job with the site, the access notes and what was done last time, and takes a tap at each step: leaving, arrived, started, finished. Parts come off the van's stock list. Photos go on the job. The customer signs on the screen and the report goes to them as a PDF before the engineer is back in the van. In a plant room or a basement with no signal it keeps working and sends everything when the signal comes back. In the office, the job's status changes on the diary as the engineer taps. The rules it holds are the ones the office argued about when it was built: - A job cannot close without a signature unless the customer is on the no-signature list, in which case a photo of the finished work stands in for it. - Before-and-after photos are mandatory on insurance jobs, and the app will not close the job without both. - The parts list the engineer sees is the van's stock, not the whole catalogue, and a part that is not on the van raises a request to the office. - Travel starts when the engineer taps leaving the previous job, not when the van moves, because that is how the customers' contracts define chargeable travel. - After a spell offline, the office copy wins on any conflict except the times and the signature, which the phone wins. The agency documented none of it. The app is the record. ## The Old Guard: the wrapped app from the PhoneGap years Built between 2010 and 2013 by an agency or a contractor, as the companion to an office job system that was already a few years old. The screens are web code wrapped in PhoneGap or Cordova (https://www.solvewithsoftware.com/modernise/phonegap-cordova), or an Ionic (https://www.solvewithsoftware.com/modernise/ionic) app on the same shell, and where the budget stretched to it, a native pair (https://www.solvewithsoftware.com/modernise/native-mobile-apps) in Objective-C and Java. Builds came out of PhoneGap Build or one developer's Mac, and the store accounts were opened in the agency's name. It runs on the Android phones and older iPhones already in the vans. Adobe closed PhoneGap Build in 2020, and the Mac with the working setup left with the developer. The camera and signature plugins it leans on stopped being maintained long ago. So the app keeps running on the handsets it was installed on, and nothing about it can be changed. ## The New Legacy: an agency's React Native app, shipped around 2020 The same app built between 2018 and 2022, usually by an agency, in React Native (https://www.solvewithsoftware.com/modernise/react-native) against an office system with a Node API (https://www.solvewithsoftware.com/modernise/react-angular-node) the same agency wrote, or put together in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or FlutterFlow (https://www.solvewithsoftware.com/rescue/flutterflow) by someone in the office who wanted the paper gone. From the office it looks current: one project for iPhone and Android, push notifications when a job is added, and a status screen showing who has arrived where. The sync is what holds it. The offline queue and its conflict rules were the hardest part to write, and the one developer at the agency who understood them left before the agency itself wound down. The last release, meant to add a job type, lost signatures captured in basements and was pulled within days, so nothing has shipped since, and the listings and build pipeline still sit under the agency's login. From 2023 a few offices tried an AI app builder for a replacement, and most stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at offline working, which a demo in the office never tests. ## What is the case for it? **The job sheet is in the office before the van has left the car park.** That is the whole case for it. The engineer finishes, taps, and the times, the parts, the photos and the signature are on the job in the office system while the engineer is still in the customer's car park. The invoice can go the same day. The customer has a report with photos in their inbox before they are back at their desk, and a query about what was done is answered by opening the job. The office gets the day as it happens. The diary shows who has arrived where and who is running late, without a phone call. The parts used are recorded when they are used, so the van stock is close to right and the parts bill lands on the right job. And a new engineer picks the app up in a morning, because it only shows them the next thing to do. ## Where it is stuck The app still runs on the phones in the vans. It just cannot be changed. **The stores moved and the app did not.** Since 28 April 2026 the App Store has needed uploads built with Xcode 26, and since 31 August 2026 Google Play updates have had to target Android 16. A wrapped app last built in 2016 meets neither, and nor does a React Native project last built in 2021. A fix, however small, cannot ship until the project builds on current tooling, and the agency that had the tooling has gone. **The keys are somewhere else.** The Apple Developer account is in the agency's name. The Android signing key was on the agency's laptop, or in PhoneGap Build, which Adobe closed in 2020. Whether Play App Signing was ever switched on decides whether the existing listing can be updated at all, and nobody in the office knows. **New phones, old plugin.** New handsets arrive and the camera plugin stops working after the next operating system update. The engineers now send photos over a messaging app and the admin attaches them to the job by hand, which is the paper problem coming back through the side door. **The app is freezing the office system.** Every change to the job system has to keep the old app's API exactly as it was, because the app cannot follow. New fields, a new job type and the rules for a new account customer all wait on an app nobody can build. ## What comes after it builds again? **An app that ships again, in your own accounts, and then gets better one screen at a time.** Each builds on what the app already does. **A build the stores accept.** Store accounts and signing keys in the business's name, a project that builds on what the stores now require, and a test release on a few engineers' phones first. The fix the engineers have been asking for is the first thing through. **The screens kept, the shell replaced.** An app that installs on the phones the engineers carry today and can be updated when the stores change their rules. Where the app is web code in a shell, the screens carry across and each plugin is mapped to a maintained one or rewritten. Where it is a native pair or an ageing framework project, bringing it current is weighed against one fresh build on the same office system. The assessment chooses the route and prices both. **Offline that holds.** A queue that survives a plant room and a basement, with the conflict rules written down and tested, not discovered. **Photos and signatures as records.** They land on the job and the asset in the office system, where the history is searchable and the report is built from them, not in the app's own database or an email. **Any handset.** iPhone or Android, company phones or the engineer's own, so a new handset is a purchase rather than a project. **The office system free to change.** A version on the link between app and office, so a new field or job type does not break the app in the vans, and a new screen does not wait on the office. The old app is not switched off for any of this, whichever generation it is. It keeps working until the last handset has swapped. ## What could AI do in the engineer's hand? **Save the typing and the scrolling on site: the data plate read from a photo, the site's history read for the engineer.** AI is worth having wherever the engineer would otherwise type on a small screen or scroll back through notes. Two places: **The data plate read from a photo.** Every boiler, panel and unit carries a label with the make, the model and the serial, usually in a cupboard with poor light. The engineer squints and types it, or skips it and the office chases it later. With AI the engineer photographs the plate, the model and the serial are read into the asset record, and the engineer confirms them with a tap. At 60 to 250 jobs a day, with a plate to record on perhaps one job in three, that is about 20 to 80 plates, and at a couple of minutes each the typing taken out of the vans comes to about 40 minutes to three hours a day across the team. **The site's history in three lines.** A site on a long contract has years of notes behind it: what was fitted, what was quoted and turned down, which door the key opens, the site manager who wants a call before anyone arrives. The engineer scrolls, or rings the office to ask. AI reads the history the office system already holds and puts a plain-words summary at the top of the job, to read in the van before going in. If one job in ten prompts a call to the office, that is 6 to 25 calls a day, and at about three minutes each they add up to about twenty minutes to an hour and a quarter a day, most of which stops. Not worth doing: regenerating the app from the old one with an AI code tool. That produces another codebase nobody owns, with the same store problem attached. An app that cannot ship a build cannot ship an AI feature either, so both wait for the first stage and an office system that takes changes safely. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back on the app and the office system as they stand. ## The stages, and why the keys come first Keys first, then a build, then the shell, with the old app on the old phones as the fallback throughout. 1. **Accounts, keys and a build.** The Apple and Google accounts into the business's name, the Android signing key found or Play App Signing established, the project building on what the stores now require, and a test release on the stores' test tracks. This goes first because nothing can reach an engineer's phone until it exists. 2. **The waiting fix.** Shipped through the old shell to a test group of engineers, then to everyone. The office sees the first update in years. 3. **The shell, or the rebuild.** The screens carried into a maintained shell with the plugins mapped, or the app built again on the same office system, screen by screen, to the test group first. 4. **Offline, then photos and signatures into the office records.** Each a stage, each priced on its own. 5. **A version on the link between the app and the office,** so the two move independently from here on. 6. **Retire the old app** when every handset has the new one. The last to go is usually the engineer with the old phone who likes it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an engineers' app that means getting the project building in a clean environment, listing what the stores reject, establishing whose name the accounts and keys are in, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for an engineers' app takeover What the assessment establishes for an engineers' app, and why each item matters: | Check | Why it matters | |---|---| | Is the app web code in a shell or a native pair, and which versions of each? | Sets the distance to a build the stores accept and whether a build pipeline exists at all. PhoneGap Build closed in 2020. | | Does it build on a clean machine with what the stores now require? | App Store uploads need Xcode 26 from 28 April 2026, and Google Play updates must target Android 16 from 31 August 2026. Until it builds, nothing ships. | | Whose name are the Apple Developer and Google Play accounts in, and where is the Android signing key? | A lost key without Play App Signing means a new listing and lost installs. This is established before anything else. | | Which plugins does it use, and which have a maintained equivalent? | Camera, signature, barcode, location, file storage. Each is a plugin to map, rewrite or drop. | | What link does it talk to on the office system, who owns it, and does it carry a version? | That link is the join between the app and the office system. Without a version on it, it freezes both. | | How does offline work, and what happens on a conflict? | The queue and the conflict rules are the part engineers feel and the part most often undocumented. | | Where do the photos and signatures go today? | The app's own database, an email attachment or the office system. Each is a migration. | | Which handsets are in the vans, and on which OS versions? | Decides the minimum the new build must support and how the rollout is staged. | ## Questions Q: Can the engineers keep using the old app while the new one is built? A: Yes. The old app keeps talking to the same office system and the same data. Engineers move across in groups, starting with the ones who will tell you what is wrong, and the old app is retired when the last handset has swapped. Q: The agency has our Apple and Google accounts. Are we stuck? A: Usually not, but it is the first thing to find out. Apple accounts can be transferred and certificates reissued. Google holds the Android signing key if Play App Signing was enabled, and the upload key can be reset. If it was never enabled and the key is gone, the app is republished as a new listing, which the assessment says up front. Q: Do we lose the job data in the app? A: No. The jobs, the photos and the signatures live in the office system, or in the database behind the app, not on the phones. What is only on a phone, usually a queue of unsynced jobs, is drained before that handset is swapped. Q: Should we start the app again or keep what we have? A: It depends on what the app is. Where the screens are web code in a shell, they usually keep their code and the shell is swapped for a maintained one. A native pair is sometimes cheaper to build once from scratch than to bring both projects current. The assessment prices both routes and says which. --- # The job sheet and diary system that runs your engineers URL: https://www.solvewithsoftware.com/systems/field-services/job-sheet-engineer-scheduling-system Title: Job Sheet and Scheduling Modernisation Description: The job sheet and diary system that runs a service company's engineers, where AI helps first, and what modernising it brings. From £395 + VAT. Last reviewed: 2026-09-14 A job sheet and engineer scheduling system is the office's picture of the day: every job, which engineer has it, what they took with them, what they did, and what to bill. Solve With Software takes over systems like this that were written for one service company years ago, keeps them running, and modernises them in stages, so the scheduler keeps the diary they know while the job sheet moves onto the engineer's phone. AI helps first at the inbox, reading the job requests that arrive by email and drafting each job for the scheduler to check. The assessment prices each stage before you commit. The Old Guard: Written between 2004 and 2013 by a contractor or a local firm, in Access and then .NET over SQL Server, on a Windows server in the office. The New Legacy: Put online between 2016 and 2022 by an agency or a freelancer in React, Node or .NET Core with an engineers' app, or in Power Apps or Bubble. Where AI helps: Job requests drafted from the inbox: 40 to 150 jobs a day at a couple of minutes each works out to about one to five hours of keying a day. ## Inside a job sheet and scheduling system A diary on one screen, a printer beside it, and a pile of job sheets waiting to be keyed in. A typical business running one of these has 8 to 25 engineers in vans, one office with three or four people in it, and somewhere between 40 and 150 jobs a day across a few thousand customer sites, some on contract and most on call-out. Plenty of firms this size run a bought job management package, some beside a homegrown system or the other way round. This page is about the homegrown diary, or a package customised past the point of upgrade. Whichever generation built it, the office leans on it for the same day's work. In the office's words, it takes the call, finds the site and its equipment, raises the job with a priority and a promised date, and drops it into an engineer's slot. It prints the job sheet: site, access notes, the fault, the parts to take. The engineer fills it in by hand, gets it signed, and it comes back in the van on Friday. Someone keys in the times and the parts, the job is costed, and the invoice is raised. On Monday the service manager runs the outstanding-sheets report and goes looking for the missing ones. It has lasted because of what it knows: - The callout rate depends on the customer, the time band (before 8, after 5, weekends and bank holidays) and whether the site is inside the M25. - Travel is charged from the previous job for most customers, and from the depot for two account customers whose contracts predate the rule. - Parts are marked up on a sliding scale by cost band, except parts fitted under a maintenance contract, which go at cost plus a fixed fitting charge. - A job cannot be invoiced until the sheet is back and marked signed, unless the customer is on the list for whom a PO number is enough. - Some engineers cannot go to some sites: a customer's vetting, a Gas Safe category, or a site manager who asked for someone else in 2019. None of that is in a manual. It is in the code, and in the scheduler's head. ## The Old Guard: a Windows diary that outgrew Access Written between 2004 and 2013, usually by a contractor or a small local firm. It often began as a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database an office manager put together, and grew into a .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) Windows program over SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) when Access could not cope with the number of people in it. The Sage export (https://www.solvewithsoftware.com/modernise/sage-integrations) arrived when the accounts moved off a separate ledger, and the Access front end never quite left: the parts list and a couple of reports still open in it. It runs on a Windows server in the office, and the grid opens on the scheduler's PC and nowhere else. The contractor who wrote it now answers one email in three, and the firm that keeps the office PCs patched will not open the code. So every new rate since has been squeezed into the old time bands rather than added, and the job sheet still comes back in the van on Friday. ## The New Legacy: the diary an agency put online around 2018 The same diary built between 2016 and 2022, by a small agency or a freelancer, as a web system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core) with an engineers' app in React Native (https://www.solvewithsoftware.com/modernise/react-native), or put together in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or Bubble (https://www.solvewithsoftware.com/rescue/bubble) by an office manager with a knack for it. The diary opens in a browser, the engineers see their jobs on a phone, and a facilities manager or two has a login to check on their sites. What pins it down is the rate card. The agency wrote the time bands and the travel rules into the code, so each new account customer meant a quote from them, and the last one went live charging travel twice on every weekend job. The office reversed it by hand and the rates have been frozen since, while the agency was bought and stopped taking small work. From 2023 some owners had a second go in an AI app builder, and those diaries tend to stall (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the Sage link, the one piece that has to agree with the accounts to the penny. ## Why does the office depend on it? **One person runs the diary for twenty vans, and every job that gets done gets billed.** The grid is what lets a small office keep that many engineers busy. Every engineer's day and every open job are on one screen, and moving a job from Tuesday to Wednesday, or from one van to another, is a drag. The sheet the engineer picks up at seven in the morning came off the same grid, so the day the scheduler planned is the day the vans run. The other half is the invoice. Because the sheet closes the job and the job raises the invoice, nothing that was done goes unbilled, and it goes out at the right rate. The Monday report is why the engineers hand their paperwork in. The Sage batch is why month end takes half a day. And when a customer rings about a site, the history is on screen before they have finished the sentence: what was fitted, when, by whom, and what was said last time. ## Where it starts to drag Systems like this do not break. They fall behind the vans. **The job sheet is still paper.** Between the engineer finishing and the office raising the invoice there is a gap of two days to a week while the sheet finds its way back and someone types it in. Sheets get lost, parts get missed off, and the handwriting on a Friday afternoon is a guess. On the older systems the paper never went away; on the newer ones it came back, for every engineer whose phone the app will not install on. **The diary lives on one screen.** The grid was built for the scheduler's PC and opens nowhere else. The service manager rings in from a site to ask where an engineer is, the on-call person takes the weekend from a printout, and when the scheduler is off the diary is run by whoever can be spared. **The server has a date on it.** The database usually sits on SQL Server 2016, on a Windows Server 2016 box in the office. SQL Server 2016 updates ended in July 2026 and Windows Server 2016 ends in January 2027. Moving it needs the contractor back, and nobody has managed to pin them down. **The customers ask for things it cannot send.** A facilities manager wants a confirmation when the job is booked, a text when the engineer is on the way, and a report with photos the same afternoon. The office does what it can by hand from the shared inbox, which works for the customers who shout loudest and not for the rest. ## What changes when it's modernised? **The same diary, with the engineers, the customers and the accounts connected to it.** **The job sheet on the engineer's phone.** The engineer sees the job, records the times, picks parts from a list, takes photos, gets a signature, and the sheet is in the office before the van has left the car park. The invoice can go that afternoon. The phone writes into the same database the diary reads. **The diary in a browser.** The same grid opened in a browser, on the same data, so the service manager sees it on a tablet, the on-call person sees the weekend on a phone, and a second scheduler can run a region without a second PC in the office. **The rate card on a screen the office owns.** The time bands, the travel rules and the parts markup come out of the code into tables the office can see and change. A new account customer with its own rates becomes a Tuesday-afternoon job instead of a developer change. **Confirmations and on-the-way texts.** A confirmation when the job is created, a text when the engineer taps travelling, and the signed sheet with photos emailed as a PDF when the job closes. Nobody in the office types any of it. **A daily Sage run that has been tested.** With the sheet arriving electronically the weekly batch can become a daily one. The export is tested against the Sage version in use before anything else moves, because month end is the thing that must not break. The old program is not switched off for any of this, whichever generation it is. It gets added to. ## Where would AI earn its keep on a job system? **In the words around each job: requests in, reports out, and the questions nobody built a report for.** AI reads, drafts and searches well here, and is no help deciding who goes where. Three places: **Job requests read from the inbox.** Work arrives as emails, portal notifications and purchase orders as PDFs, and someone retypes each one. AI reads the request, matches the site and its equipment, and drafts the job with the fault, the priority and the PO number filled in, for the scheduler to check and drop into a slot. At 40 to 150 jobs a day and a couple of minutes of keying each, the retyping the office stops doing works out at about one to five hours a day. **The engineer's notes turned into the customer's report.** What comes back from site is typed shorthand or a voice note from the van: fan motor replaced, drain blocked, quote needed. AI turns it into a clean report with the times and parts from the job record, and the engineer approves it on the phone before it sends. The fussier customers expect a dozen or so of these reports a day, and at about five minutes of tidying each that comes to around five hours a week, most of a working day, off the admin's desk. **Questions put to the job history.** Which contract sites have had the same unit out three times since spring? Which follow-up quotes were never booked? Today each is an export and a morning with a spreadsheet, and two such questions a week add up to about a day of the service manager's week. AI answers in plain words from a read-only view of the job history and lists the jobs behind the answer, so the service manager checks a list instead of building one. Not worth doing: letting AI allocate the day's jobs. The scheduler knows which engineer the site manager will let in, who is on a course on Thursday, and who should not get two jobs in Southend on the same day. A diary where one rate change can break the invoice run cannot take anything new, so AI waits for the first stage to make changes safe. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows which of these would pay back soonest on the system as it stands. ## The order the work goes in Stabilise, then the phone, then everything else one stage at a time, with the old program as the fallback throughout. 1. **Stabilise.** Source code found and building, or recovered from the agency's hosting account, the database on a version that is still supported with a backup that has been restored, and a test copy so changes can be tried away from the live diary. It goes first because everything after it depends on it, and it takes the January 2027 date off the table. 2. **The job sheet on the phone.** Writing into the existing database. The office sees no change except sheets arriving during the day instead of on Friday. 3. **Confirmations, texts and the PDF report.** From the same job record, triggered by what the engineer taps. 4. **The diary in a browser.** Run alongside the old grid until the scheduler stops opening it. 5. **The rate card as data, and the daily Sage run.** Each a stage, each priced on its own. 6. **Retire the old program** when nothing depends on it. The last thing to go is usually the parts list in Access. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a job system that means a few days with the scheduler and the code, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a job sheet and scheduling system takeover What the assessment establishes for a job system, and why each item matters: | Check | Why it matters | |---|---| | Is the source available for the .NET application and the Access front end, and does it build? | Job systems were often built by one contractor. Without the source the options narrow to keep-running or replace. | | Which SQL Server version, on which Windows Server, and where is the backup? | SQL Server 2016 updates ended July 2026 and Windows Server 2016 ends January 2027. A backup that has never been restored is a hope. | | Where do the rate card, the time bands and the parts markup live: tables, code or a report? | Rules in code mean every rate change is a developer change. Rules in data can be given a screen. | | How does a job sheet close a job, and what are the exceptions? | Every invoice waits on a sheet being marked signed, so this rule and its exceptions decide when the business gets paid. The PO-is-enough list is one to keep. | | What does the Sage export produce, for which Sage version, and what happens when Sage upgrades? | A file drop or a COM link built for one Sage version breaks quietly when Sage moves. It is tested before anything else changes. | | Which reports does the office run the week on? | The Monday outstanding-sheets report and the engineer utilisation report carry rules of their own. | | How many people are in the system at once, and where does it lock? | A diary built for one scheduler behaves differently with three. Locking decides how the browser version is built. | | Which parts of the Access front end are still used? | Often the parts list and two reports. Each is a small stage or a thing to retire. | ## Questions Q: Can the engineers keep using paper while this happens? A: Yes, and some will for a while. The job sheet on the phone writes into the same database the paper is keyed into, so an engineer on paper and an engineer on the phone produce the same job record. Most offices move engineers across a few at a time and stop printing sheets when the last one has swapped. Q: Our system is a .NET program with an Access database behind it. Does that change anything? A: It changes the first stage. An Access database behind a Windows program has a size ceiling and a way of handling several users that gets worse as the business grows. The usual first move is to take the data off the Access file and onto a supported database, and leave the program alone. The office notices nothing except that it stops locking up. Q: We have rates and rules nobody has written down. Will they survive? A: They are the first thing found and the last thing changed. The assessment goes through the code and the reports with the people who use them and writes the rules down. They then go into tables the office can see, and the old code stays as the reference until the new screens match it. Q: Will it still talk to Sage? A: The Sage link is tested before anything else moves, against the version in use. Electronic invoicing is due to become mandatory for business-to-business VAT invoices from April 2029, so the invoice run is planned with that date in view. If the accounts package is about to change, that goes into the plan too rather than being discovered later. --- # The planned maintenance system that keeps your customers compliant URL: https://www.solvewithsoftware.com/systems/field-services/planned-maintenance-certificates-system Title: Planned Maintenance Modernisation Description: The contracts, schedule and certificates system behind a maintenance business, where AI helps, and what modernising it brings. From £395 + VAT. Last reviewed: 2026-09-14 A planned maintenance and certificates system holds every contract, site and appliance a service business looks after, when each is next due, and the certificate that proves the visit happened. Solve With Software takes over systems like this, often an Access database with Crystal certificates and a spreadsheet doing the reminders, keeps them running, and modernises them in stages so one due list drives the reminders, the certificates and the customers' audits. AI helps first by checking each certificate against the asset record before it goes out, so the admin reads the few that look wrong rather than all of them. The assessment prices each stage before you commit. The Old Guard: Started between 2005 and 2012 as an Access database, with Crystal certificates and an Excel workbook of reminders, on the office PCs. The New Legacy: Built between 2016 and 2022 by a freelancer or agency in PHP or React with a tablet visit form, or in Zoho Creator or Power Apps. Where AI helps: Certificates checked against the asset record: 30 to 100 a day at a couple of minutes reading each comes to about one to three hours a day. ## The contracts, the sites and the certificate for each visit A typical business running one of these has 6 to 20 engineers, one office, and somewhere between 1,500 and 6,000 sites under contract: housing providers, managing agents, schools, care homes and small commercial customers. It books 30 to 100 planned visits a day and issues a certificate for most of them. Whichever generation built the system, the due list and the certificates hang off it in the same way. Day to day it holds each contract: its sites, what is covered, how often, the price and the renewal date. Under each site sit the assets: the boiler, the alarm panel, the extinguishers with their dates, the emergency lights. Each month the office runs the due list, books the visits, and the engineer goes out with a printed form. When it comes back the admin keys in the results, produces the certificate as a PDF and emails it. Sixty days before a certificate runs out a letter goes to the customer, often from a workbook kept beside the system. When a housing provider asks for its property list with dates, someone builds it in Excel on the provider's own references. The rules it carries are the ones the trade runs on: - A gas safety record issued in the two months before the due date keeps the original anniversary, so the date does not creep forward each year. - Extinguishers get a basic service every year, and water-based and standard powder ones an extended service every fifth year (sealed powder ones every tenth), and the system knows which year each one is in. - A housing provider's properties are reported on the provider's own reference, not the system's site number, and the mapping lives in the workbook. - A visit that finds an appliance at risk raises a remedial job and a re-visit, and the certificate does not issue as satisfactory until the re-visit closes it. - Access to a tenanted property is attempted three times, with a letter at each, before the customer is told, because that is what the contract says. The compliance manager knows all of this. The system knows most of it, and the workbook holds the rest. ## The Old Guard: Access, Crystal and a workbook of reminders Started somewhere between 2005 and 2012 as a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database, built by the compliance manager of the day or a contractor, with the certificate layouts done in Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports) so they looked like the paper forms the trade recognises. An Excel workbook (https://www.solvewithsoftware.com/modernise/excel-to-system) grew up beside it for the reminder run and the month's due list, because the Access query took the morning and nobody trusted it. Some offices also have an SSRS (https://www.solvewithsoftware.com/modernise/ssrs) report server that an IT firm added later for the customers who asked for reports. It all runs on the office PCs, with the Crystal runtime installed on each machine that prints certificates. The person who built it has left, and the compliance manager who inherited it is the only one who understands the workbook. Layouts are not changed, because nobody has the tools or the nerve. It cannot be opened on site, the mail merge runs from one PC, and every certificate still starts life as a paper form. ## The New Legacy: certificates on a tablet, built in about 2019 The same contracts and certificates built between 2016 and 2022 by a freelancer or a small agency, as a web system in PHP (https://www.solvewithsoftware.com/modernise/php) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) with the engineers' visit form in React Native (https://www.solvewithsoftware.com/modernise/react-native), or put together in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by a compliance manager who wanted rid of the workbook. The engineer fills in the form on a tablet, the certificate issues as a PDF, and the reminders go out by email on their own. The dates are the trouble. The anniversary rule and the fifth-year extinguisher service were coded as the freelancer understood them, and the one change made since pushed a batch of gas safety anniversaries forward a year before anyone noticed. The date rules have been left exactly as they are ever since, and the freelancer, now salaried elsewhere, answers questions as a favour. From 2023 a few compliance managers tried again in an AI app builder, and most of those stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) once the housing providers' own property references had to be matched. In the office, every gas safety date the system proposes is now checked against the last certificate before the visit is booked. ## What does the business get from it? **Nothing under contract falls out of date without someone knowing.** The due list is the reason the certificates get done in time. Every site has a next-due date, the month's visits are booked from it, and the office can see in September what October looks like. The certificate that goes out has the engineer's registration and the appliance's details filled in from the record, and it looks like the certificate the customer's auditor expects. That record is what answers the questions. When a housing provider's compliance officer, an insurer or an accreditation body asks which properties were visited, when, and by whom, the answer is on the screen. The asset register, with the model, serial and age of every appliance, is what makes a remedial quote a ten-minute job. And because every contract carries a renewal date and a price, the year's income is visible a year ahead. ## Where the office has outgrown it The system still works. The trouble is what has grown around it. **There are two lists, and they disagree.** The reminder run and the due list moved into a spreadsheet years ago. Now the compliance manager reconciles the workbook against the system by hand before the month's letters go out, and the housing providers' property references live only in the workbook. When the compliance manager is on leave, the reminders wait. **The certificates only print on some PCs.** The layouts are Crystal Reports tied to a runtime years out of support, which the IT company coaxed onto new machines when Windows 10 support ended in October 2025. On two of the PCs it will not print, so the admin emails the visit to a colleague. The next refresh is the one where it stops. **The audit asked for what it cannot show.** Social landlords must have every existing tenancy's electrics inspected by 1 November 2026, then at least every five years, and Awaab's Law, in force for social landlords since 27 October 2025, sets fixed timescales for investigating and fixing hazards such as damp and mould. So a housing provider's audit of its contractors asks for inspection dates by property, response times, the overdue list with the reason for each, and evidence of the access attempts. Whichever generation the system is, it has the dates. The reasons and the response times sit in a spreadsheet, in emails and in the compliance manager's memory, and the answer takes a week. **One person holds it together.** The queries, the workbook's formulas and the way a re-visit gets closed are known to the compliance manager and nobody else. New office staff take months to learn it, and there is no manual. ## What does modernising it put right? **One due list, with the reminders, the certificates and the customers' audits all coming off it.** **One due list, and no workbook.** The anniversary rule, the fifth-year service and the access attempts go into the system as rules, the workbook's columns become fields, and the reminders come off the same list the diary is booked from. **Reminders that send themselves.** Sixty days out, thirty days out, and the access-attempt letters, by email or post, each logged against the property. Nobody runs a mail merge. **The certificate from the visit record.** The engineer's results, entered on site, produce the certificate as a PDF the moment the visit closes, with the registration and the appliance details on it. It looks the same as the Crystal one, prints on any PC, and the customer has it the same day. **The customer's compliance position on a login.** A housing provider or a managing agent sees its properties, the certificate on each, the overdue ones and the reason: no access, second letter sent, remedial pending. Each remedial shows when it was reported and when it was closed, which is the response-time evidence their audit now asks for. **Remedial work quoted from the register.** With the model, the serial and the age on the record, the quote for the defect the engineer found is drafted at the contract's rates while the engineer is still on site. **Written down and shared.** The rules the compliance manager carries come out into screens and a short manual, so the office can run a month without them. The old screens stay open through all of it, Access or browser. New pieces are added on the same data; nothing is switched off. ## What could AI do with years of certificates? **Check every certificate before it leaves, read the paper history into the register, and answer the questions the reports were never built for.** On a certificates system AI is useful with the records, not the forecasts. Three places: **Each certificate checked before it issues.** Results come back with a serial that does not match the record, a reading outside its range, or a visit date that would move the anniversary. AI compares each certificate with the asset record and the rules the system already holds, and flags the ones that look wrong. At 30 to 100 certificates a day and a couple of minutes reading each, the admin's checking works out at about one to three hours a day, and it shrinks to the handful flagged. **The filing cabinet read into the asset register.** Years of certificates sit as scans and paper forms, and the register has gaps: a boiler with no serial, an extinguisher with no install year. AI reads the scans, pulls out the model, the serial, the dates and the readings, and proposes each against the right property and asset for the admin to accept or correct. Every remedial quote that needed a serial from the cabinet stops needing the trip. If three or four quotes a day need one, at a quarter of an hour each, the trips come to about four to five hours a week. **Questions put to the records.** Which of one provider's properties have a remedial still open, and for how long? Which have had two no-access visits and no second letter logged? AI answers in plain words from the visits and letters on file, read-only, and lists each record behind the answer for the compliance manager to check. Each took a morning of filtering, so one or two a week came to half a day to a day. Not worth doing: predicting which boilers will fail from a few thousand visit records. The engineers' judgement and the manufacturer's age guidance do better. All three need records that can be changed without upsetting the due list, and making that safe is the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back on the system as it stands. ## The stage order for a certificates system The workbook first, then the paper, then the customers, with the Access screens as the fallback until the office chooses to close them. 1. **Stabilise, and rescue the workbook.** The source of the Access application and the Crystal layouts found, or the agency's code recovered, the data off the Access file and onto a supported database if it is still in one, a backup that has been restored, and the workbook's columns and rules captured into the database so there is one due list. It goes first because every stage after it reads from that list, and the workbook is the biggest risk in the office. 2. **Reminders from the system.** Off the same list, logged against the property. 3. **The certificate from the visit record.** The engineer enters results on site, the certificate issues on the spot, and the Crystal runtime is retired PC by PC. 4. **The customer login.** The compliance position for each housing provider and managing agent, on their own references. 5. **Remedial quoting from the register.** Priced on its own, once the register is complete. 6. **Retire the Access screens and the workbook** when nothing depends on them. The last thing to go is usually a customer report somebody built in SSRS. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a certificates system that means a few days with the compliance manager and the workbook, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a planned maintenance system takeover What the assessment establishes for a certificates system, and why each item matters: | Check | Why it matters | |---|---| | Is the source of the Access application and each Crystal layout available? | The certificate layouts are the part the customers see. Rebuilding them from the .rpt files is quicker than from a printout. | | Which rules live in the Excel workbook and nowhere else? | The anniversary rule, the property reference mapping and the access-attempt letters often exist only as formulas and columns. | | Is the data in an Access file or SQL Server, and how big is it? | An Access file with a few thousand sites and years of visits is near its ceiling, and it is the evidence behind every certificate. | | Which Crystal runtime, on which PCs, and where does it not print? | Windows 10 ended October 2025. The runtime that survived the move to Windows 11 is the one that fails at the next refresh. | | How does a visit become a certificate, and what stops one issuing? | The at-risk, the re-visit and the no-access outcomes are the rules an audit asks about, along with when each remedial was reported and closed. | | What do the customers receive today, and in what form? | PDFs by email, a spreadsheet on their property references, a portal upload. Each is a thing to keep working. | | Which SSRS reports exist, and who reads them? | A report server added by an IT firm is often unowned and half used. Each report is a specification or a thing to retire. | | Who holds the engineers' registrations and their expiry dates? | A certificate with a lapsed registration on it is a problem for the customer as well as the business. | ## Questions Q: We run the reminders from a spreadsheet. Does that have to change? A: Not on day one. The first stage captures what the spreadsheet knows into the system so the two agree, and the spreadsheet stays as the check until the system's list has been right for a few months. Then it stops being needed. Q: Can we keep our certificate layouts? A: Yes. The layouts are rebuilt to look the same, from the Crystal files where they exist, because the customers and the auditors recognise them. What changes is where they come from, the visit record rather than a runtime on one PC. Q: Do we lose the history when we move off Access? A: No. The visits, the certificates and the assets move across as they are, and the old PDFs stay linked to the property. Where the history is on paper, back-filling it is a stage the assessment prices. Q: Will the housing providers get what their audit asks for? A: That is what the customer login is for. Their properties, the certificate on each, the overdue ones and the reason, on their own references. The compliance position becomes a screen rather than a week of Excel. --- # The system that runs your skip hire yard URL: https://www.solvewithsoftware.com/systems/field-services/skip-hire-waste-collection-system Title: Skip Hire System Modernisation Description: The bookings, rounds, weighbridge and transfer note system behind a skip hire yard, where AI helps, and what modernising it brings. From £395 + VAT. Last reviewed: 2026-09-14 A skip hire and waste collection system is the yard's memory: every skip and where it is, every round, every weighbridge ticket, and the transfer notes that keep the Environment Agency satisfied. Solve With Software takes over systems like this that were written for one yard years ago, keeps them running, and modernises them in stages, so the booking desk keeps the screen it knows while the drivers, the weighbridge and the website get connected to it. AI helps first with the tip's disposal invoices, matching each line to a weighbridge ticket so the yard manager handles only the lines that fit nothing. The assessment prices each stage before you commit. The Old Guard: Written in VB6 over SQL Server by a contractor from the early 2000s to about 2012, wired to the weighbridge from a server in the yard office. The New Legacy: Built between 2016 and 2022 by a local agency in PHP or React with a drivers' app, or in Zoho Creator or Bubble, and never wired to the weighbridge. Where AI helps: Tip invoices matched to weighbridge tickets: several hundred lines a month at a minute or two each comes to a day or more of matching by hand. ## Bookings, rounds, skips and the weighbridge A typical business running one of these has 8 to 20 vehicles, skip loaders mostly with a roll-on-off and a grab lorry or two, somewhere between 400 and 1,500 skips in circulation, one yard with a weighbridge and a transfer station, and an office of three or four handling 60 to 200 movements a day. The job the system does for the yard is the same whichever generation built it. In the office's words, it takes the booking by phone or from the website form that arrives as an email, prices it, books the council permit if the skip is going on the road, and puts the delivery on tomorrow's round. Each vehicle gets a printed run sheet: deliveries, exchanges and collections in order. Every skip has a number, and the system knows whether it is in the yard, on a customer's drive or on the back of a lorry. When a load comes over the weighbridge the ticket is written against the job. Each collection prints a transfer note, signed in the cab. At the end of the quarter the return goes to the Environment Agency from a report, and at the end of the week the invoices go to Sage. What it knows is why nobody has replaced it: - The price depends on the skip size, the postcode band and the waste type, with a surcharge for plasterboard and a refusal list the desk cannot override. - A skip on the road needs a council permit, and the system knows which postcodes belong to which council, what each charges and how many days' notice each wants. - A skip out longer than 14 days attracts a weekly rental charge, except for the account customers with extended hire written into their terms. - Account customers charged by weight get the weighbridge ticket's net weight set against the job, over the tonnage their price includes. - A transfer note does not print without the EWC code, the producer's SIC code and the carrier registration number on it. The people who wrote those rules in have moved on. The rules stayed behind. ## The Old Guard: a VB6 booking screen wired to the weighbridge Written in the early 2000s by a contractor who knew the trade, and added to until around 2012. A Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) program with the data in SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) and a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database beside it for the permit letters and the reports. The weighbridge supplier's engineer wired the indicator into it over a serial lead, and the Sage export (https://www.solvewithsoftware.com/modernise/sage-integrations) came later, when the accounts stopped being retyped. It runs on a server in the yard office and one PC in the weighbridge cabin. The contractor has retired, and the firm that keeps the office PCs running leaves the program well alone. The server stays put because the weighbridge link is the one part nobody could wire back up, so it sits long out of support while the drivers carry paper. ## The New Legacy: online bookings and a drivers' app from 2020 The same yard system built between 2016 and 2022 by a local agency or a freelancer, as a web system in PHP (https://www.solvewithsoftware.com/modernise/php) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) with a drivers' app in React Native (https://www.solvewithsoftware.com/modernise/react-native), or put together in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Bubble (https://www.solvewithsoftware.com/rescue/bubble) by someone in the office who had had enough of the grey screen. Bookings come in from the website priced, the drivers tick off the round on a phone, and the skip register opens in a browser. The weighbridge is where it came unstuck. The indicator only speaks serial, and a system in a browser has no way to read a lead in the weighbridge cabin, so every ticket is still keyed in and the loads in and out never quite reconcile. Then a change to the postcode bands started booking permits with the wrong council, and the office has booked them by phone ever since. The agency has folded. From 2023 a few yards tried a fresh start in an AI app builder, and those tend to stall (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the transfer note, which has to carry the EWC code and the carrier number every time. The office still trusts it to say where every skip is, and handles the weights and the permits the old way, at the keyboard and on the phone. ## What would the yard lose without it? **Every skip is either earning or accounted for, and every movement gets billed.** The register is the heart of it. A skip is a numbered asset, and because every delivery, exchange and collection goes through the system, the yard knows where all of them are without walking round. A skip that has been on a drive for three weeks shows up on the list and the rental charge goes on the invoice. Nothing goes out unbooked and nothing comes back unbilled. The paperwork is the other half. The transfer notes, the weighbridge tickets and the quarterly return all come from the same records, so when the Environment Agency visits or a customer's auditor asks for the duty-of-care trail, it exists. The weighbridge tie-up means the loads in and the loads out reconcile, which is what the return depends on. And the Sage batch keeps the accounts within a week of the yard. ## Where the yard is paying for it Systems like this keep going long after the people who built them have stopped. **The weighbridge runs through a cable nobody can replace.** The indicator talks to the system over a serial lead into one PC in the weighbridge office, and the database behind it sits on SQL Server 2008 R2, whose updates ended in July 2019, on a Windows Server 2012 box that ended in October 2023. The insurer's cyber questionnaire asked about both this year. The weighbridge supplier will service the indicator, but not the lead or the PC at the other end of it. **The transfer note is still a carbon copy.** On the older systems it always was, and on the newer ones it is again wherever the drivers' app will not install. Every collection produces a paper note signed in the cab and filed in the yard. Mandatory digital waste tracking starts on 1 October 2026 for permitted and licensed waste receiving sites in England and Wales, with carriers and brokers following from October 2027. A yard with its own transfer station is in that first wave, and the system has no way to record what it receives as data. **Bookings arrive twice.** The website form emails the office, someone keys it into the system, then rings the customer back to confirm the price and the permit. The customer rings twice more to ask when the skip is coming. The morning goes on calls the system could have answered. **The margin per skip is known a month late.** The tip's disposal invoices arrive weeks after the loads, and the yard manager matches them to weighbridge tickets by hand. Which skips lost money, which postcode band is underpriced and which account customer is over their tonnage are month-end questions, when they get asked at all. ## What is there to gain from modernising it? **The same booking desk, with the drivers, the weighbridge, the website and the tip connected to it.** **Bookings that land in the system priced.** The website form writes the booking straight in, with the size, the postcode band, the waste type and the permit worked out by the rules the desk uses, for the office to confirm rather than key. **The transfer note signed in the cab, as data.** The driver's phone carries the round, the customer signs the note on it, and the record is complete with the EWC code and the carrier number the moment it is signed. With the weighbridge ticket beside it, that is the record digital waste tracking asks a receiving site for from October 2026. **The weighbridge on a supported link.** The indicator's reading written to the ticket and the job as the lorry sits on the deck, off the serial lead and off the 2012 server. **The skip register, live.** Where every skip is, from the driver's taps: which are over their hire period and due a rental charge, which are on the road on a permit that runs out on Friday, which have sat in the yard unused for a month. **Margin per skip the week it happens.** The tip's disposal invoice matched to the weighbridge tickets and allocated to the jobs, so the underpriced postcode band shows up in a week rather than a quarter. **A server the insurer will accept.** The database and the server it sits on both on versions that are still supported, with a backup that has been restored on purpose. The questionnaire gets an answer. The old system is not switched off for any of this, whichever generation it is. It gets added to, and the desk decides when to stop opening it. ## Which of the yard's paperwork could AI take on? **The comparing and the searching: tip invoices against weighbridge tickets, and the questions no report on the yard answers.** In a skip yard AI is useful wherever one piece of paperwork has to be checked against another, or the answer sits in the records and no report shows it. Two places: **Tip invoices matched to weighbridge tickets.** The disposal invoices arrive weeks after the loads, on the tip's own references, and the yard manager matches them by hand. AI reads each invoice, matches its lines to tickets and jobs even when the references do not line up, and flags the lines that match nothing. At 60 to 200 movements a day a month's invoices run to several hundred lines, and at a minute or two to find the ticket behind each, the matching comes to a day or more. If one line in ten is left for the yard manager, that works out at a few dozen lines and an hour or two, and the margin per skip shows while it is still news. **Questions put to the skip register.** Which skips have been out longest, and on whose drive? Which account customers book inert and keep sending back mixed loads? AI answers from the bookings, the movements and the weighbridge tickets in plain words, read-only, and lists the jobs behind each answer so the desk can check before ringing anyone. With 400 to 1,500 skips in circulation, each of those questions used to mean a morning with a printout and a highlighter, and the two or three a week the yard manager wants answered added up to a day or a day and a half. Not worth doing: forecasting skip demand by postcode from a few years of bookings. The yard manager already knows the season. A system still leaning on a serial lead and an unsupported server is no place to add anything, so AI follows the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back on the system as it stands. ## How the work runs, stage by stage The server, then the receiving record, then the cab and the website, with the old program as the fallback throughout. 1. **Stabilise.** The VB6 source found and building, or the agency's code recovered, the database off SQL Server 2008 R2 and onto a version that is still supported, with a backup that has been restored, the weighbridge link proven against the new server, and a test copy of the system. This goes first because the 2012 server is the thing most likely to stop the yard. 2. **The weighbridge ticket as the receiving record, and the digital waste tracking feed.** Every load in written to its job as data, with the EWC code and the carrier, in the shape digital waste tracking asks receiving sites for from October 2026. It comes second because that date already applies to a yard with a transfer station. 3. **The driver's round on a phone,** with the transfer note signed in the cab, completing the same record from the collection end. The booking desk keeps the screen it knows. 4. **Online booking straight into the system,** priced by the desk's rules, confirmed by the office. 5. **The tip invoices matched to tickets, and the register live.** Each a stage, each priced on its own. 6. **Retire the VB6 program** when nothing depends on it. The last thing to go is usually the quarterly return report. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a skip hire system that means a few days with the booking desk, the weighbridge and the code, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a skip hire system takeover What the assessment establishes for a skip hire system, and why each item matters: | Check | Why it matters | |---|---| | Is the VB6 source available, and does it build with the components the program uses? | VB6 programs lean on third-party controls that may no longer be licensed or findable. Without a build the options narrow. | | Which SQL Server version, on which Windows Server? | SQL Server 2008 R2 ended July 2019 and Windows Server 2012 ended October 2023. Both are questions an insurer now asks. | | How does the weighbridge talk to the system, and what happens if the PC in the weighbridge office fails? | A serial lead into one PC is a single point of failure for every load in and out of the yard. | | Where do the pricing bands, the permit rules and the rental charges live? | Postcode bands and council permits in code mean every change is a developer change. | | What does the transfer note carry, and what does the quarterly return read? | The EWC codes, the carrier number and the site permit reference are the compliance record, and from October 2026 a receiving site sends them to digital waste tracking. Their source tables are the ones to protect. | | What comes from the website today, and how does it get into the system? | An emailed form keyed in by hand is a booking entered twice. Its fields are the specification for online booking. | | How are the tip's disposal invoices matched to loads today? | Usually by hand at month end. The matching rule is what makes margin per skip possible. | | Which reports does the yard run on? | The daily run sheets, the skips-out-over-14-days list and the quarterly return each carry rules of their own. | ## Questions Q: Do we have to stop using the old program while this happens? A: No. The VB6 program keeps running and the new pieces are built beside it on the same data. The booking desk keeps the screen it knows and switches when the browser version is better, and not before. Q: Our system is VB6. Can anyone still work on it? A: Yes. VB6 programs still run on current Windows and can still be built, given the source and the components the program uses. Finding both is the first job. It is a known kind of takeover, with its own page. Q: Will the weighbridge still work? A: The link is tested on the new server before the old one is touched, and it is the one piece that must work on day one. If the indicator only speaks serial, that link is kept and monitored until the weighbridge is next replaced. Q: What about the Environment Agency and digital waste tracking? A: Mandatory digital waste tracking starts on 1 October 2026 for permitted and licensed waste receiving sites in England and Wales, so a yard with a transfer station is in the first wave, and carriers and brokers follow later. The transfer notes, the weighbridge tickets and the quarterly return come out of the same records they do today, as data rather than carbon copies. That is why the receiving record is the second stage, straight after the server is safe. --- # Systems that run professional services firms URL: https://www.solvewithsoftware.com/systems/professional-services Title: Professional Services Systems Description: Systems behind law firms, accountants, brokers, recruiters, architects and managing agents, old and new, and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 Law firms, accountancy practices, insurance brokers, recruitment agencies, architecture practices and managing agents each run on a system shaped around the way one firm works, usually built years ago and often sitting beside a package bought for the rest. Solve With Software takes those systems over and modernises them in stages, so the people who use them keep the screens they know while the deadlines, the clients and the invoices come off one record. AI then reads the post, the timesheets and the documents clients send, for a person to check. The pages below describe each kind of system in both its generations, and what modernising it brings. ## Where these systems live Law firms, accountancy practices, insurance brokers, recruitment agencies, architecture practices and managing agents across the UK run systems like these, from a high street practice with a few offices to a national team running a group action or a specialist insurance scheme. Nearer home they include the firms in Colchester, Chelmsford and Ipswich. The block management system (https://www.solvewithsoftware.com/systems/construction-property/property-management-system) a managing agent runs is listed here as well as under construction and property, because an agent looks for it among the professional firms. Most have a partner or director who remembers the system going in and a practice manager who keeps it running, and the question is the same for all of them: how do we move it forward without a missed deadline, a late pay run or an unbilled month? The office is in Colchester, and the firm can be anywhere in the UK. The work runs remotely, and a firm in Essex, Suffolk or London gets a site visit when the work needs one. The regional page (https://www.solvewithsoftware.com/essex-suffolk-london) says how the local side works. ## Bought packages, and the systems built beside them Most professional firms buy their core package: the practice software, the broking platform, the candidate database, the design tools. The system these pages describe is the one the firm built for the part the package never did, and it comes in two generations. **The Old Guard** was written between the early 2000s and about 2013. The case management system (https://www.solvewithsoftware.com/systems/professional-services/bespoke-case-management-system) is a Windows client grown out of an Access database, or a bought package customised until it could not be upgraded. The claimant system (https://www.solvewithsoftware.com/systems/professional-services/group-litigation-claimant-system) is an ASP.NET Web Forms (https://www.solvewithsoftware.com/modernise/aspnet-web-forms) site built for a first big action. The accountancy practice's deadline and workflow database (https://www.solvewithsoftware.com/systems/professional-services/accountancy-practice-workflow-system) lives in Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) with a workbook beside it. The broker's scheme rating system (https://www.solvewithsoftware.com/systems/professional-services/insurance-broker-scheme-system) is Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) with a web quote form added later. The agency's pay-and-bill program (https://www.solvewithsoftware.com/systems/professional-services/recruitment-timesheet-payroll-system) runs on the .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework), and the architecture practice's project and fee database (https://www.solvewithsoftware.com/systems/professional-services/architecture-practice-project-system) is often FileMaker or Access on the studio's own machines. **The New Legacy** is the same system built from about 2016 by an agency or a freelancer: a client portal, an online quote, a timesheet app, a browser resourcing screen, or a build in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or a chain of automations (https://www.solvewithsoftware.com/rescue/zapier-make). Since 2023 some firms have tried again with an AI builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the part with the rules in it. Newer, and just as hard to change. ## What modernising usually brings a firm The people who use the system reach it from where they are: the fee earner at court, the architect on site, the consultant with a client, the claimant signing on a phone. The pieces a deadline depends on come out of the system rather than a spreadsheet: the schedule for the court, the quarterly updates for Making Tax Digital clients, the insurer's monthly bordereau, the Tuesday pay run, the stage invoice. The rules the firm runs on, the key dates, the rating tables, the pay and charge rates, the fee stages, come out of the code into screens the firm can see and change. And the whole thing comes off servers and databases whose support dates have passed, onto supported versions with a backup that has been restored on purpose, while the screens the firm knows keep working until each is replaced. Once the system is safe to change, AI takes the reading off the desk as well: the letter from the other side drafted into an attendance note, the client's records sorted against the job's checklist, the proposal form read into a quote, the photographed timesheet matched to its assignment, the client email that asks for work outside the appointment flagged before it is done for nothing. Each system page works out the time that gives back at its own volumes. The old system stays on throughout. Each piece is added beside it, on the same data, and the firm switches when the new screen is better than the old one. ## Questions Q: Does the firm have to stop using its system while it's modernised? A: No. The old system stays on throughout, and each new piece is added beside it on the same data, so a colleague who opens a record in the new screen and one who opens it in the old one see the same thing. The firm switches when the new screen is better than the old, and not before. Q: We already pay for a package. Why would we keep a system of our own beside it? A: Because the package does not do the part your system does: the deadline rules, the scheme rating, the pay and charge rates, the fee stages. The assessment looks at both, says where the package could take over and where the firm's own system is the better home for the rules, and prices the link between them. Sometimes the answer is to move a piece into the package, and the report says so. Q: Our system holds client files, personal data and privileged material. Who sees it during the work? A: The data stays where it is. Any copy used to try a change on is handled as the personal data it is, with access limited to the people who need it and the copy destroyed when the stage ends. The assessment records what is held, who can see it and how long each kind of record is kept, which is also the answer the firm needs for its own data protection file. Q: Is there anything AI can do for a system like ours? A: Yes, once the system is safe to change, and in the reading rather than the judgement. It reads what already arrives in writing, the letter from the other side, the records a client sends, the proposal form, the timesheet, and drafts the entry for someone to check. It also answers questions from the firm's own records and flags entries that do not fit. It does not give legal or tax advice, set a rate, decide a referral or a status; a person does those. It comes after the first stage, and the assessment maps where it would pay back on the system as it stands. Q: What does it cost, and how soon is there something to show? A: The assessment is from £395 + VAT, with an exact price before you commit, and it produces a report with costed options and a fixed price for each. The report is yours. Take it to us, another developer, or nobody. The first stage after that usually has something working within about six weeks, each stage priced before it starts. --- # The deadline and workflow system beside your practice software URL: https://www.solvewithsoftware.com/systems/professional-services/accountancy-practice-workflow-system Title: Accountancy Workflow Modernisation Description: An accountancy practice's own deadline, workflow and onboarding system, what modernising it brings, and where AI helps first. From £395 + VAT. Last reviewed: 2026-09-14 An accountancy practice workflow system is the practice's own record of every client, every deadline and every job, kept beside the bought tax, accounts and practice software: records requested and chased, the review, the approval, the filing, and the anti-money-laundering file behind each client. Solve With Software takes over workflow systems like these, keeps them running, and modernises them in stages, so the practice manager keeps the deadline list they trust while the practice gets the jobs board in a browser, the Making Tax Digital quarters tracked and chasers that can be seen going out. AI helps first with the records clients send, sorting each bank statement or receipt against the job's checklist and drafting the chaser for whatever is still missing. The assessment prices each stage before you commit. The Old Guard: Built 2004 to 2012 by the practice manager, a partner or a contractor in Access, with an Excel deadline workbook and Word chaser letters, on the office server. The New Legacy: Built 2016 to 2022 by an agency or freelancer as a client portal and jobs board, in Zoho Creator or Power Apps, or as a chain of Zapier or Make automations. Where AI helps: Client records sorted against each job's checklist: 150 to 400 items a day in January at a minute and a half each comes to about four to ten hours a day. ## The deadline list the whole practice works from Ask what is due this month and everyone opens the same screen, usually called Jobs. A typical business running one of these has 15 to 80 staff in one to three offices, 1,500 to 6,000 clients (limited companies, sole traders, landlords and partnerships), partners and managers reviewing the work, and a practice manager who owns the system. Through January, 150 to 400 emails, uploads and envelopes of records can arrive in a day, beside a few hundred client emails and a few new clients a week. Built in 2006 or in 2020, it does the same job. Practices this size almost always buy their tax, accounts production and practice software, and that stays. This page is about the piece built beside it: the practice's own client, deadline and workflow database, its onboarding and anti-money-laundering records, the chasers, and sometimes a records portal. From each client's services and year end it works out the deadlines: accounts to Companies House nine months after the year end, corporation tax paid nine months and a day after the period, the company tax return twelve months after it, self assessment online by 31 January, VAT returns a month and seven days after each period, plus the confirmation statement and payroll. Each deadline becomes a job that moves from records requested through chased, received, in progress, review and sent for approval to filed. It also prints engagement letters, holds the client due diligence the Money Laundering Regulations 2017 require, sends the chasers and shows the workload by person. The practice's own rules: - Records are requested three months before the deadline, chased at six weeks and at four, and the chasers stop once the records are logged in. - No client is taken on until the ID for each director and owner and the risk assessment are recorded. - A job over the fee the partners set, or any partnership return, goes to partner review before approval. - A job cannot be marked filed without its submission reference. - A Making Tax Digital for Income Tax client gets update deadlines on 7 August, 7 November, 7 February and 7 May, then the final declaration. ## The Old Guard: an Access file, a deadline workbook and a mail merge Built somewhere between 2004 and 2012, usually by the practice manager, a partner who was good with computers, or the contractor who already looked after the network. A Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database holds the clients and the jobs, an Excel deadline workbook (https://www.solvewithsoftware.com/modernise/excel-to-system) sits beside it with a tab for each month, and the chaser letters come out of a Word mail merge run from a query saved long ago. Where the client list outgrew one Access file, the tables went into SQL Server (https://www.solvewithsoftware.com/modernise/sql-server), and some practices keep each client's folder in a SharePoint (https://www.solvewithsoftware.com/modernise/sharepoint) library. It lives on the office server and opens on every desk. The partner who built it now has a client list of their own and has not opened the design view in years. So each new service arrives as a column in the workbook rather than a table in the database, and the workbook has become the list people check first. From home or the second office, the Access file opens over a remote session or not at all. ## The New Legacy: a client portal and a chain of automations, around 2019 The same system built between 2016 and 2022, as a client portal and workflow board from an agency or a freelancer in PHP (https://www.solvewithsoftware.com/modernise/php), React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), or put together in Zoho Creator (https://www.solvewithsoftware.com/rescue/zoho-creator) or Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by someone in the practice. In other offices it is a chain of Zapier or Make automations (https://www.solvewithsoftware.com/rescue/zapier-make) joining the onboarding form, the email account and the practice software. From the office the chasing seems to run itself: clients upload statements to the portal, jobs move across a board, and reminders go out without anyone opening Word. The chasing is what strands it. When the onboarding form gains a field, or the practice software changes what it sends, one step in the chain stops, and records requests stop going out with no error shown anywhere. Nobody notices until a client is late for a deadline they were never asked about. The board was drawn around one return a year per service, so the Making Tax Digital quarters have nowhere to sit, and the freelancer who could add them has taken other work. Since 2023 a few practices have started again in an AI app builder and stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) before the deadline rules worked. ## Why does the practice trust it with the deadlines? **Every client's deadlines worked out in advance, the chasing done on time, and the due diligence on file before the first job opens.** Nobody can carry a few thousand clients' year in their head. Enter the year end and the services once, and every date for that client follows, year after year, with the job opened and the first records request sent in good time. When a client rings to ask whether the return has gone in, the answer is on the screen with its submission reference. The workload view is what the partners watch from November to January. It shows who has forty jobs waiting in review and who has four, so work moves before late filing penalties land on clients. And when the anti-money-laundering supervisor asks to see the due diligence on any client, the ID, the risk assessment and their dates are already on file. It has lasted because it follows the practice's own way of working. ## Where it has fallen behind the practice Systems like this seldom stop working. The rules around them move on instead. **Making Tax Digital multiplied the deadlines.** From 6 April 2026, sole traders and landlords with qualifying income over £50,000 send quarterly updates, and the threshold falls to £30,000 from April 2027 and £20,000 from April 2028. Each such client now has four update deadlines and a final declaration where there was one return, and neither the Access database nor the agency's board can hold them, so the quarters live in a spreadsheet beside the system. **Directors now verify their identity.** Companies House identity verification became mandatory for directors and people with significant control from 18 November 2025, existing directors verifying at their company's next confirmation statement. The onboarding and deadline records were not built to show who has verified or when each is due, so the practice manager keeps that list by hand. **The server's software ran out of updates.** SQL Server 2016 updates ended in July 2026, SharePoint Server 2016 and 2019 left support on 14 July 2026, and Windows 10 support ended in October 2025. That server holds ID documents for thousands of people. **One person can change it.** In the older system that is the partner who built it; in the newer one, a freelancer or the login the automations run under, set up by someone who has since left. A new service or rule waits for them. ## What would modernising it give the practice manager? **The same clients, deadlines and jobs, in a browser, with every date worked out and every chaser accounted for.** **Deadlines from the services, quarters included.** Each client's dates follow from the year end and the services, the four Making Tax Digital updates and the final declaration among them, with the 2027 and 2028 thresholds kept as a setting. The quarters spreadsheet can be deleted. **Chasers the office can see.** Every records request and reminder is logged against its job with the date it went, and a request that failed to send shows on the board that morning. **The board from anywhere.** The jobs, the review queue and the workload by person open in a browser in either office, at home or on a phone, with one login each. **An onboarding file that answers the supervisor.** The ID, the risk assessment and each director's Companies House identity verification sit against the client with their dates, ready to show for any client on request. **Records sent straight to the job.** Clients upload statements and receipts against the job that asked for them. **Off the unsupported server.** The data on a database that still gets updates, a backup restored on purpose, and the ID documents held as the data protection file says. **The rules in settings.** The chaser intervals, the partner review threshold and the rule that a filed job needs its reference are written down with the practice manager and kept where they can change them. Neither the Access database nor the portal is switched off for any of this. Each piece is added beside it, on the same client records. ## Which parts of the January rush could AI take on? **The sorting, matching and typing between a client sending something and a person working on it, never the tax.** **Records sorted against the checklist.** Bank statements, receipts, spreadsheets and phone photos arrive, and someone opens each, finds its job and ticks it off. AI does that first pass, marks what the checklist is still waiting for and drafts the chaser for a person to send. At 150 to 400 items a day through January and a minute and a half saved on each, that comes to between about four and ten hours a day across the admin team. **Client emails put on the right job.** Most of the few hundred a day ask whether records arrived or what is owed. AI matches each to its client and job and drafts the reply from the job's status for a person to send. Take 200 of them a day at a minute saved on each: that works out at over three hours a day for whoever watches the shared inbox. **The onboarding file read in.** A new client's passport, proof of address and Companies House details are read into the file for a person to check against the documents. At four new clients a week, with half an hour's typing on each becoming five minutes of checking, that adds up to over an hour and a half a week, and the risk rating stays a person's to set. **Questions answered from the records.** "Which Making Tax Digital clients have not sent this quarter's records?" "Which jobs are waiting on partner review?" AI answers from the job records without writing to them, and lists every client behind the answer, so the manager opens those jobs rather than trusting a count. Filtering the workbook against the job list for 250 Making Tax Digital clients, at half a minute each, comes to about two hours a week before 7 August or 31 January. Not worth doing: AI preparing or submitting a tax return, or deciding a client's risk rating. The return is prepared in the bought tax software by someone who answers for it, and the risk rating is the practice's judgement to defend when the supervisor asks. Each of these reads from or writes to the client and job records, so none starts before the first stage makes them safe to change. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back on the practice's own records. ## Stage by stage, around the filing calendar Safe to change first, then the deadlines, then the rest, with the old system running beside every stage. 1. **Stabilise.** The Access file with its queries and mail merge templates, or the agency's code and every step of the automation chain, found and matched to what the office uses; the database on a version that still gets updates; a backup restored on purpose; a test copy that treats the ID documents as personal data. This goes first because nobody changes the deadline calendar without a copy to try it on, and the July 2026 dates are already behind it. 2. **The deadline calendar.** Each client's dates, Making Tax Digital quarters included, worked out from the existing data and run beside the workbook until the practice manager stops opening it. 3. **The jobs board in a browser.** The stages, the review queue and the logged chasers, on the same client records. 4. **The onboarding file, the records upload, the workload view.** Each a stage, each priced on its own. 5. **Retire the old system** once nothing depends on it. The last piece to go is usually the chaser letter one partner still signs. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a practice workflow system that means a few days with the practice manager, a partner and whatever built it, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for an accountancy practice workflow system takeover What the assessment settles on a practice workflow system, and why each item matters: | Check | Why it matters | |---|---| | Where does each deadline come from: a query, a date typed in by hand, or the workbook? | The dates are the reason the system exists. Hand-typed ones hide rules nobody wrote down, and the workbook often knows services the database does not. | | How are Making Tax Digital for Income Tax clients held, and where do their quarterly updates live? | From 6 April 2026 each has four update deadlines and a final declaration, and the threshold falls to £30,000 in April 2027 and £20,000 in April 2028, so the count grows each year. | | What sends the chasers, and what shows when one fails to go? | A mail merge run by hand or a chain of automations can stop without an error. The first sign is a client missing a deadline. | | Where are the client due diligence records, ID documents and risk assessments, and can they be produced for one client on request? | The anti-money-laundering supervisor can ask to see them, and they are the records the practice cannot recreate. | | Does the client record hold Companies House identity verification for each director and person with significant control? | Mandatory since 18 November 2025, with existing directors verifying at their company's next confirmation statement. Where it is kept shapes the onboarding stage. | | Which Access or SQL Server version, on which server, and who last restored a backup? | SQL Server 2016 updates ended in July 2026. An Access back end has a 2 GB ceiling a large client list can approach, and a backup nobody has restored is a hope. | | What passes between it and the bought tax, accounts and practice software, and in which direction? | Client lists and submission references are often exported as files or re-keyed. That link gets tested before anything else moves. | | What is in the SharePoint client folders besides documents? | SharePoint Server 2016 and 2019 have been out of support since 14 July 2026. Lists, forms and workflows in the library are pieces of the system to rebuild or retire. | ## Questions Q: Can the office keep using the old system through January? A: Yes. The old system, the Access database or the portal, keeps running and each new piece is built beside it on the same client records, so a job moved on the new board shows the same stage on the old screen. Nothing is switched over in the weeks before 31 January, and the practice manager decides when the old screen stops being opened. Q: Will our deadline rules and chaser intervals survive? A: They are the first thing found. The deadline calculations, the chaser intervals, the partner review threshold and the rule that a filed job needs its submission reference come out of the queries and the workbook, get written down with the practice manager, and go into settings the practice can see and change. Anything the workbook knows that the database does not is counted as well. Q: Does this replace our tax and accounts software? A: No. The bought tax, accounts production and practice software stays where it is. The work is on the system the practice built beside it: the client list, the deadlines, the jobs, the chasers and the onboarding file. Where the two share client details or submission references today, the assessment traces how, and what the bought software allows. Q: Can it hold our Making Tax Digital clients and directors' identity verification? A: Yes, and those are often the first reasons the old system gets looked at. Each Making Tax Digital client gets the four quarterly update deadlines and the final declaration, with the thresholds for April 2027 and April 2028 kept as settings. Each director and person with significant control gets their Companies House identity verification recorded against the client, with the confirmation statement it is due at. --- # The project and fee system that tells your practice what to invoice URL: https://www.solvewithsoftware.com/systems/professional-services/architecture-practice-project-system Title: Architects' Fee System Modernisation Description: An architecture practice's own project, timesheet and fee system, what modernising it changes, and where AI helps first. From £395 + VAT. Last reviewed: 2026-09-14 An architecture practice's project and fee system is where each job's appointment, fee stages, weekly time and invoices meet: what the project was quoted, what it has cost in time, and what can be invoiced this month. Solve With Software takes over project systems that practices built for themselves and modernises them in stages while they keep running, so the office works in familiar screens while the directors get every fee basis in one place, timesheets from site and invoice drafts straight from stage progress. AI helps first with the weekly timesheets, flagging the entries that do not fit before the week locks. The assessment prices each stage before you commit. The Old Guard: Built 2002 to 2012 by a partner in FileMaker on the studio Macs, or by a contractor in Access on Windows, with an Excel resource planner beside it. The New Legacy: Built 2016 to 2022 by a freelancer or small agency as a browser timesheet and resourcing system, or in Power Apps; since 2023, tried in AI builders. Where AI helps: Timesheets checked before the Monday lock: 40 sheets at five minutes each is over three hours; a dozen flags at two or three minutes each is half an hour. ## Projects, timesheets and the fee each stage has earned A typical business running one of these has 10 to 60 staff in one or two studios and 40 to 150 live projects at different stages. Fees are a lump sum split across the work stages, a percentage of the construction cost, or hourly for small jobs. Everyone fills in a timesheet by project and stage each week, invoices go out monthly against how far each stage has got, and the directors keep a plan of who works on what. The drawings are made in design software the practice buys, and most practices this size buy their accounts package too. This page is about the system between the two, which small and mid-size practices have often built for themselves. Whether a partner built it in 2005 or a freelancer in 2019, it does the same work. In the office manager's words, it holds the project register (client, site, appointment, fee basis, stages, team), produces fee proposals, takes the weekly timesheets, sets time cost against fee earned for each stage, drafts the invoices, records additional services and fee variations, carries the planning application and appointment dates, keeps the CPD records, and holds the resourcing plan by person and week. The rules in it are the practice's own: - A stage is invoiced by the percentage the project architect marks complete, and never past 100 per cent until a fee variation is agreed. - Additional services are recorded separately and not invoiced until the client has agreed them in writing. - Timesheets lock each Monday, and late time goes through the office manager. - Each grade has a cost rate, set each April, and time cost against fee is worked from it. - A percentage fee is recalculated when the cost plan changes, not when the tender comes back. None of it is in the staff handbook. It is in how the fee screen behaves. ## The Old Guard: a partner's FileMaker file or a contractor's Access database Built somewhere between 2002 and 2012, and which version a practice has tends to follow its computers. In a studio of Macs, a partner with a feel for databases built it in FileMaker: a layout for projects, one for timesheets, and a fee screen that came later. In a Windows office a contractor wrote it in Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access), and when the file slowed under years of timesheets the tables went into SQL Server (https://www.solvewithsoftware.com/modernise/sql-server) with the Access forms left in front. Either way the resource planner and fee tracker stayed in Excel (https://www.solvewithsoftware.com/modernise/excel-to-system), and the project folders sit on the office server or in SharePoint (https://www.solvewithsoftware.com/modernise/sharepoint). Its stages are still labelled A to L, the RIBA work stages from before 2013, so someone keeps a table mapping them to the stages 0 to 7 of the RIBA Plan of Work, and every monthly fee report passes through it. The partner who built the FileMaker version runs projects now and has no time to open it, and the contractor stopped answering years ago. It opens on the machines in the studio and nowhere else. ## The New Legacy: timesheets on a phone and fees on a page, from about 2018 Between 2016 and 2022 the same job went into a browser. A freelancer or a small agency wrote a timesheet and resourcing system in PHP (https://www.solvewithsoftware.com/modernise/php) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), or the associate who looked after the office computers assembled one in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps). From the studio it looks current: a timesheet filled in on a phone after a site visit, the resource plan as coloured bars across the coming weeks, a fee page for every project. The fee stages are what hold it back. They were built for the practice's standard appointment, so every project with a different stage split, or a fee worked out as a percentage of construction cost, is tracked in a spreadsheet beside the system, and the monthly invoice figures come from that spreadsheet. The stage list is shared by every project, so a change made for one job moves the fee earned on all of them, and since that happened once nobody has touched it. The freelancer answers an email every few weeks. Since 2023 a few practices have started over in an AI app builder, and those stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) where the timesheets had to meet the fees. Every new project goes in on the standard split, and the spreadsheet corrects it. ## Why do the directors trust it? **It tells the directors, project by project, what the fee was, what the time has cost and what can be invoiced this month.** The gap between fee and time spent is where a practice makes or loses money on a job, and this system shows it while there is still a stage left to act on. Every hour is booked to a project and a stage and every grade carries a cost rate, so a stage that has used most of its fee with the drawings half done shows up that month, not at the final account. The invoices come out of the same records. The project architect marks the stage progress, the draft follows, and the office manager sends it without redoing the sums. Additional services sit apart until the client agrees them, so the practice can show what was asked for and when. The resource plan answers the question behind every new enquiry: who could do the work, and when. ## Where the fees and the rules have moved on Systems like this keep producing the fee report. What has changed is everything around it. **The Building Safety duties have nowhere to live.** The Building Regulations principal designer and principal contractor dutyholder roles and competence requirements apply from 1 October 2023, with gateway approvals by the Building Safety Regulator for higher-risk buildings. A practice needs appointment and competence records for each project, and neither the FileMaker file nor the agency's system has a field for them, so they live in a folder and a spreadsheet. **CPD is kept somewhere else.** The ARB's CPD scheme became mandatory for registered architects from 2025, with fire and life safety and environmental sustainability as mandatory topics, recorded per architect. The old CPD screen was a training log with a date and a course title, so each architect's record is kept by hand beside it. **The machines under it have run out of dates.** Windows 10 support ended in October 2025, and the Access version often runs on Windows 10 PCs. SQL Server 2016 updates ended in July 2026, and SharePoint Server 2016 and 2019 ended on 14 July 2026, which covers the library many project folders sit in. **The fees still pass through Excel.** In both generations the fee tracker and resource planner are spreadsheets fed from the system, so Monday's figures are as old as the last copy. Invoice drafts are retyped into the accounts package, and the invoice route needs settling before electronic invoicing is due to become mandatory for business-to-business VAT invoices in April 2029. ## What would a modernised version give the practice? **The same projects and fee stages, opened in a browser or on a phone, with the side spreadsheets folded in.** **Every fee basis on the project.** A lump sum by stage, a percentage of construction cost recalculated when the cost plan changes, or hourly, with the stage split set per project. The spreadsheet for the awkward projects goes, and the A to L stages are mapped once, on the record. **Fee earned against time cost as the week locks.** Monday's locked timesheets priced at the April grade rates against each stage's fee, on a page the directors read that afternoon. **Invoice drafts from stage progress.** The project architect's percentage complete drafts the invoice, capped at the stage fee until a variation is agreed, and the draft reaches the accounts package without being retyped. **Additional services with the agreement attached.** Each request recorded against the project with the client's written agreement, and nothing invoiced until it is there. **Appointments, dutyholder roles and CPD in the records.** The principal designer or principal contractor role and competence evidence on each project, gateway dates for higher-risk buildings, and each architect's CPD against the mandatory topics. **The resource plan beside the fee left.** Who is booked on what in the coming weeks, next to the fee each stage has left, from the studio, home or site, with one login, a supported database and a tested backup. Whichever generation the practice has, it stays in use while this happens, and each new piece sits next to it on the records it already keeps. ## Where would AI help the studio and the office? **In the checks and the looking back that happen around the fees, never in the design.** Each of these works on records the system already holds and leaves the decision with a person. **Timesheets checked before the week locks.** The office manager reads every timesheet for time booked to a closed stage, a person on a project they are not resourced on, or a week short of contracted hours. AI reads them against the stage list and the resource plan and lists only the entries that do not fit. In a practice of 40, reading 40 timesheets at five minutes each takes over three hours of a Monday morning; a dozen flagged lines at two or three minutes each take half an hour. **Emails that ask for more than the appointment.** A client asking for another layout option or an extra meeting may be asking for work outside the appointment. AI flags those emails and drafts a note for the project architect to agree a fee. Written from the email rather than pieced together at month end, each note takes a quarter of an hour less, and twenty requests a month works out at five hours. **A first fee proposal from the practice's own history.** For a new enquiry, AI finds similar past projects in the register and drafts a proposal from their stages and the time each stage took, for a director to price. At four proposals a month, pulling those hours from old timesheet reports at half a day each comes to two days; checking the drafts at about an hour each comes to half a day. **Questions put to the records in plain words.** Which stage 4 projects have used most of their fee? Who is free in three weeks? AI answers from the timesheets, fees and resource plan, read-only, showing the records it used. Before the directors' Monday meeting, lining the planner up with the fee tracker at a minute a project across 60 live projects adds up to an hour, which the answers replace. Not worth doing: AI producing drawings, or estimating the construction cost a fee is worked from. The drawings belong in the design software and the cost plan is the cost consultant's, and a fee resting on a model's guess at the build cost is one no director could defend to a client. All four depend on timesheet and fee records that can be changed without risk, which comes with the first stage and not before. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows which of the four would pay back first here. ## Data first, fees second, and the old system kept running Make the data safe first, then take the fees out of the spreadsheet, with the old system in use until the end. 1. **Stabilise.** The FileMaker file, or the Access database and its SQL Server tables, copied and checked against the version in daily use, the Excel planner and fee tracker collected, the SharePoint project folders listed, the database on a supported version, a backup restored as a test, and a copy to try changes on. This goes first because every figure a director reads comes out of that data, and Windows 10, SQL Server 2016 and SharePoint Server 2016 and 2019 have all passed their dates. 2. **Fees and stages in a browser.** Every fee basis and stage split, reading and writing the existing data, the A to L mapping settled, with the fee tracker kept beside it until a month's figures agree. 3. **Timesheets and invoice drafts.** The week filled in at a desk or on a phone, the Monday lock kept, and drafts passed to the accounts package. 4. **Resourcing, appointments and CPD.** Each priced as a stage of its own. 5. **Retire the old system** once nothing is typed into it. The directors' resource spreadsheet tends to be the last thing closed. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a project and fee system that means a few days with the directors, the office manager and the data, finding the fee rules, the stage mapping and the spreadsheets behind the reports, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for an architecture practice project system takeover What the assessment establishes on a practice's project and fee system, and why each item matters: | Check | Why it matters | |---|---| | Is the system a FileMaker file or an Access database, which version, and is the copy found the one the office runs? | Both keep their logic in scripts, forms and layouts inside the file. The running copy is the specification, and the version says which machines it still opens on. | | Where are the stages defined, and how do the old A to L stages map to 0 to 7? | The mapping decides the fee earned on every older project. If it lives in one person's spreadsheet, it is written down first. | | How is each fee basis stored, and which projects are tracked in a spreadsheet instead? | Lump sum, percentage and hourly fees are often handled differently, and the projects kept outside the system are the ones the new fee screen has to fit. | | Where do the grade cost rates live, and what happens to past time when April's rates go in? | Restating old time at new rates changes the margin on finished stages. The rule is found before anyone relies on the figures. | | What locks a timesheet, and who can change a locked week? | The Monday lock is what the fee reports trust, and the office manager's route for late time is a rule to keep. | | Which Windows, which SQL Server and which SharePoint, and when did someone last restore a backup? | Windows 10 support ended in October 2025, SQL Server 2016 updates in July 2026 and SharePoint Server 2016 and 2019 on 14 July 2026. Until a backup is restored, nobody knows it works. | | How does an invoice draft reach the accounts package? | Retyping, a file export or an import each set a different stage, and electronic invoicing is due to become mandatory for business-to-business VAT invoices from April 2029. | | What is recorded per project for appointments and dutyholder roles, and per architect for CPD? | The dutyholder and competence requirements from 1 October 2023 and the ARB's CPD scheme from 2025 decide which new records the system has to hold. | ## Questions Q: Do timesheets and invoicing carry on in the old system during the work? A: Yes. The FileMaker file, the Access database or the agency's system stays in use, and each new piece runs next to it, reading the same records. Timesheets keep locking on Monday and invoices keep going out. Staff change screens once the new one does the job better. Q: Our older projects are still on stages A to L. Is that history kept? A: Yes. The old stages stay on the old projects, and the mapping to stages 0 to 7 is written down once and held with the data, so a report across old and new projects adds up without the side table. The time and fees recorded against each stage stay as they are. Q: We buy our accounts package. Does that change? A: No. The accounts package stays, and the invoice drafts are passed to it rather than retyped. The assessment checks which version is in use and how it takes invoices in, and because electronic invoicing is due to become mandatory for business-to-business VAT invoices from April 2029, that route is checked against it too. Q: Would bought practice management software do this instead? A: It might, and the assessment says whether it would. The question is whether it handles the practice's own fee bases, stage splits, additional services rule and resource plan without a spreadsheet beside it. Where it does not, modernising the system the practice already has keeps those rules. --- # The case management system your firm runs its matters on URL: https://www.solvewithsoftware.com/systems/professional-services/bespoke-case-management-system Title: Case Management System Modernisation Description: A law firm's own case management system: key dates, documents and bills, what modernising it brings, and where AI helps first. From £395 + VAT. Last reviewed: 2026-09-14 A bespoke case management system is the record of every matter a law firm has open: the client, the key dates, the tasks, the documents and the bill, arranged the way that firm works, whether it was written in-house or began as a package customised past the point of upgrade. Solve With Software takes over case management systems like these, keeps them running, and modernises them in stages, so the fee earners keep the screen they know while the firm gets the matter in a browser, documents on a supported store and bills posted straight to accounts. AI helps first with the post, reading each letter or court order onto its matter and drafting the attendance note and next task for a secretary to check. The assessment prices each stage before you commit. The Old Guard: Written 2004 to 2012 by an IT manager or contractor in .NET, Access and SQL Server, or a bought package scripted past upgrading, on a server in the office. The New Legacy: Built 2016 to 2022 by an agency or freelancer as a browser system with a client portal, or in Power Apps; since 2023, sometimes started in an AI app builder. Where AI helps: Post read onto each matter with the note and task drafted: some 300 items a day at two minutes each comes to about ten hours a day across the secretaries. ## The system behind every matter in the firm Everyone in the building opens the same screen, and in most firms it is called the Matter. A typical business running one of these has 40 to 120 staff across two or three offices, about half of them fee earners, with a few thousand live matters, several hundred opened and closed each month, and a few hundred letters, emails and reports arriving on them every day. Most firms that size run a bought case management package; this page is about the firm whose system is its own, written in-house or customised past the supplier's upgrades. Whichever generation built it, in 2007 or 2020, the job is the same. In the fee earner's words, it opens the matter and runs the conflict check, holds the key dates (limitation, exchange and completion, hearings), works through the task list for the matter type, merges precedents into Word, files the documents, records time, drafts the bill and sends it to accounts. A personal injury department also exchanges low-value claims with the claims portal through it, and the compliance partner runs a report from it before every Lexcel visit. The rules it keeps are why the firm has never replaced it: - A limitation date on a personal injury matter reminds the fee earner at six months, three months and one month, and the supervising partner at one month, and the reminder cannot be dismissed, only actioned. - A purchase matter will not move to exchange until the searches are recorded, the mortgage offer is on file and the client's ID check carries a date. - A legal aid bill has its own rate table, its own template and time codes a private client bill never shows. - One commercial client's matters carry its own reference beside the firm's, and its bills go to a named person on a fixed day each month. - A file cannot be archived until the client account balance is nil and the destruction date, which depends on the matter type, is set. Ask for a written version of any of that and someone will point at the screen. ## The Old Guard: written in-house, or a package customised past upgrade Built between 2004 and 2012, in one of two ways. Some firms had their IT manager, or a contractor from a legal software house, write it for the busiest department, usually conveyancing or personal injury, and it spread one matter type at a time: a Windows client on the .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework), grown out of a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database one department still uses as its front end. Others bought a package, then scripted its workflows and added screens in-house until the supplier's next version would have overwritten the lot, so the upgrade never came. Either way the data is in SQL Server (https://www.solvewithsoftware.com/modernise/sql-server), the documents in a SharePoint (https://www.solvewithsoftware.com/modernise/sharepoint) library or on file shares, and the bills come out of Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports). It runs on a server in the main office, installed on every desk, with the other offices reaching it over the link between sites. The person who wrote it, or scripted the package, left years ago, and no one has edited a line since. That keeps the reminders firing on time and keeps a new matter type waiting. Court is out of reach without a remote session, and the SharePoint farm lost its support in July 2026. ## The New Legacy: the agency's browser version from 2018 The same matter system built between 2016 and 2022, by a small agency or a freelancer as a browser system in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), or assembled in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) by an IT manager whose licences already covered it. From the fee earner's side it looks modern: the matter opens in a browser, the key dates reach a laptop at court, and clients upload their ID through a portal. The key dates are what strand it. The reminder rules run as a scheduled job on the agency's server, where the firm cannot see them, and when a field was added to the exchange checklist the one-month warning to the supervising partner quietly stopped. It was weeks before anyone missed it, and the firm has not risked another change. The lender panel questionnaire now asks who holds administrator access to client data, and the answer is an agency that has stopped returning calls. Since 2023 a few firms have started one in an AI app builder, and it stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) short of the conflict check, the part that has to be right. ## What does the firm get from it? **Every matter in one place, every key date surfaced, and a bill built from the time already recorded.** The matter screen is what lets a firm of this size run thousands of files without any one of them depending on one person's memory. When a fee earner is off sick and the client rings for news, the answer is on the screen, with the last note and the next task. The key dates are the part the firm depends on most, and the part the professional indemnity insurer asks about at renewal. A limitation date that surfaces on its own, to the right people, at the right intervals, is the difference between a diary and a negligence claim. Then the bill. Because time is recorded against the matter as it happens and the bill is drafted from it, WIP turns into an invoice without anyone reading a paper timesheet. The compliance answers come out of the same place at audit time: file reviews sampled, conflicts run, key dates cleared. It has lasted because it was shaped around the firm, one department at a time, and no package straight out of the box has matched it since. ## Where it has stopped keeping up Systems like this seldom break. They fall behind the way the firm now works. **The documents sit on a farm out of support.** The library is SharePoint 2016 or 2019, both out of support since 14 July 2026, beside a SQL Server 2016 database whose updates ended the same month. The firm's IT support can keep both servers running but has no fixes left to apply, and the Cyber Essentials application stalls on both. **The fee earners left the building.** A desktop system on the office network cannot be opened from court, from home or from a client's boardroom without a remote session that drops. So the key dates get copied into Outlook, the task list into a notebook, and the system catches up when someone is back at their desk. **The chap who wrote it has retired.** Since then a precedent is changed by editing the merged Word file by hand, and a new matter type or a new step in a scripted workflow, which used to take him an afternoon, waits until somebody finds a developer willing to open the code. **The bill reaches accounts on paper.** Whether the draft prints from Crystal or downloads from the agency's screen, it is re-keyed into the accounts system, and the two disagree at month end often enough that the cashier keeps a reconciliation spreadsheet beside them both. ## What would modernising it change? **The same matter, in a browser, with the documents, the clients and the accounts connected to it.** **The matter from anywhere.** Key dates, tasks and the last note in a browser at court, at home or across the client's table, on the same database. The Outlook copy and the notebook stop. **Documents on a supported store.** The library moves off the farm one department at a time, with the link from every matter kept working. The Cyber Essentials form gets a straight answer. **Precedents the firm can edit.** The letters come out of the code into templates a senior secretary maintains, with the merge fields listed beside each one. A new matter type stops waiting for a developer. **Bills posted, not printed.** Time and disbursements go to the accounts system as a posting, and month end reconciles itself. The cashier's spreadsheet goes. **A view for the client.** The client sees the stage their matter has reached and uploads a document without phoning, which takes the "where are we" calls off the secretaries. **The rules where the compliance partner can see them.** The limitation reminders, the exchange gate and the archive rule come out of the code into settings, written down with the people who rely on them. Neither the desktop system nor the browser version is switched off for any of this. Each piece is added beside what the firm already runs. ## Where would AI give the fee earners time back? **In the reading between a letter arriving and the file moving on, and in the questions no report was written to answer.** AI belongs in the post and the records, never in the advice. **Incoming post read onto the matter.** A letter from the other side, a medical report or a court order arrives, and a secretary reads it, files it, types the attendance note and sets the next task. AI reads it, matches it to the matter and drafts the note and the task, pointing out any date it mentions for the fee earner to confirm. At a few hundred items a day, say 300, and two minutes saved on each, that comes to about ten hours a day across the firm's secretaries. **Questions asked of the matters in plain words.** "Which of our matters have had no activity for a month?" "Which key dates fall next week with no task behind them?" AI answers from the matter records on read-only access, with no way to change a matter or a key date, and lists every matter it counted, so the supervising partner opens the files rather than trusting a number. Setting the aged matters report against the key dates list by eye, at a second or two a line across some 3,000 live matters, works out at an hour or so a week, and the list takes its place. **The file review sample read before a visit.** Before a Lexcel visit the compliance partner reads a sample of files against the checklist. AI reads the same sample and lists what each file is missing. With one file from each of 20 to 60 fee earners at half an hour's reading a file, the sample comes to ten to thirty hours; reading AI's list at five minutes a file brings that to between about two and five hours, spent on the gaps. Not worth doing: AI giving legal advice, or setting a limitation date. Advice is the fee earner's to give; a model can point at a date in a letter, but a person sets it, and the rule stays where the insurer can see it. All three need matter records that can be reached and changed without risk, which a system like this seldom offers before the first stage. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows which would pay back soonest on the firm's own matters. ## The order the work runs in Make it safe to change first, then one piece at a time, with the old system as the fallback throughout. 1. **Stabilise.** Source code, or the package's in-house scripts, found and matched to what the fee earners run, the database on a version still supported, the SharePoint farm inventoried down to each list, form and workflow, a backup restored on purpose, and a test copy that treats the client data as the personal data it is. This goes first because nothing that holds court deadlines gets changed without a copy to try the change on, and because the July 2026 dates are already behind it. 2. **The matter in a browser.** Key dates, tasks and the last note, reading and writing the existing database, with the old screens left as they are. Fee earners open it from court first, where the old one cannot go. 3. **Documents off the farm.** One department at a time, links kept, the old library read-only once its last matter has moved. 4. **The billing posting, the precedent templates, the client view.** Each a stage, each priced on its own, each live in weeks. 5. **Retire the old system** when nothing still depends on it. Expect the conflict check to go last, because everyone trusts the old one. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a case management system that means a few days with the fee earners, the cashier and the code, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a case management system takeover What the assessment pins down on a case management system, and why each item matters: | Check | Why it matters | |---|---| | Is the source code available, or for a customised package the in-house scripts, and do they match what the fee earners run? | Firm systems were often built or scripted by one person. A system with no source can be kept running but not changed, and a package's customisations decide whether it can take an upgrade at all. | | Where do the key-date rules live: in code, in database triggers, or in a report? | The reminder rules are what the insurer is relying on. They get found and written down before anything moves. | | Which SQL Server, on which server, and who last restored a backup? | SQL Server 2016 updates ended in July 2026. A backup nobody has restored is a hope. | | What is in SharePoint besides documents: lists used as tables, InfoPath forms, workflows? | SharePoint 2016 and 2019 have been out of support since 14 July 2026, and each form or workflow is a piece of the system to rebuild or retire, never to copy. | | How does a document link to its matter? | By URL, by ID or by folder name decides how hard the document move is and whether old links survive it. | | What passes to the accounts system, in which direction, and on which version? | The posting link is the one finance notices. It gets tested before anything else moves. | | How does the personal injury department exchange low-value claims with the claims portal: through the system, or by typing into the portal? | A volume PI team sends and answers claims on the portal every day against the protocol's time limits. That link has to keep working through every stage, so it is traced first. | | What personal data is held, who can see it, and what is the retention for each matter type? | A legal file holds special category data. The answer shapes the hosting, the access rules and the archive stage. | ## Questions Q: Can the fee earners keep working in the old system while it's modernised? A: Yes. The old system, the Windows client or the customised package, keeps running and the new pieces are built beside it on the same database. A fee earner who opens the matter in a browser at court and the old screen back at the desk sees the same record. They switch when the browser is better, and not before. Q: Our documents are all in SharePoint. Does that have to move? A: The on-premises farm is out of support, so at some point yes, but the move is a stage of its own, one department at a time, with the links from each matter kept working. What is inside the farm besides documents, the lists and forms and workflows, is counted in the assessment, because those are the pieces that need rebuilding rather than copying. Q: Will our precedents and key-date rules survive? A: They are the most valuable part of the system and the first thing found. The reminders, the gates on a matter and the archive rules come out of the code, get written down with the people who use them, and go into settings the firm can see. The precedents come out as templates a senior secretary can edit. Q: Can it post to our accounts system instead of us re-keying bills? A: Usually. Most legal accounts packages have an import or an interface the billing stage can post to, and the assessment checks which version and which link is in play. Client money stays in the accounts system. The case management side sends the bill and reads the balance. --- # The claimant system that runs your group action URL: https://www.solvewithsoftware.com/systems/professional-services/group-litigation-claimant-system Title: Group Litigation System Modernisation Description: The system that moves thousands of claimants through a group action, what modernising it brings, and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A group litigation claimant system carries thousands of claimants through one process: enquiry, sign-up, evidence, the court's schedule, settlement and payment out, against deadlines set by an order. Solve With Software takes over claimant systems that were built for one action and have carried every action since, keeps them running, and modernises them in stages, so the team keeps the screens it knows while the schedule comes out of a button and sign-up finishes on a phone. AI helps first on the evidence queue, reading each uploaded payslip or statement into the claimant record for a paralegal to confirm, and in flagging sign-ups that look like someone already on the books. The assessment prices each stage before you commit. The Old Guard: Built 2008 to 2013 for the firm's first big action by a contractor or small agency, in ASP.NET Web Forms over SQL Server, on a server the firm runs. The New Legacy: Built 2016 to 2022 by an agency or freelancer as a claimant portal in React, PHP or .NET Core, or in Power Apps; since 2023, some begun in an AI app builder. Where AI helps: Uploads read into claimant records: 200 sign-ups a day, two uploads each, three minutes' typing saved per upload, comes to twenty hours a day across the queue. ## The site the action runs on A team of paralegals works in one site and one claimant list for the life of the action. A typical business running one of these has a group action team of 15 to 60 paralegals and case handlers across one or two offices, with between 5,000 and 50,000 claimants on the books, arriving in the hundreds a day while a claim is advertised and in ones and twos for years after, and a shared inbox taking hundreds of claimant emails a day. Whichever generation built it, for an action in 2010 or one in 2021, the job is the same. In the case handler's words, it takes the enquiry from the website or the call centre, runs the questionnaire that decides whether the person fits the cohort, sends the retainer for signature, collects the ID check and the evidence, moves each claimant through the stages the court's order sets, produces the schedule of claimants for the court, sends the bulk letters and emails, and at the end records the settlement, works out the deductions and pays out. Two pieces matter more than the rest: the stored procedure that decides who is on the schedule, and the duplicate check. The rules it holds are the ones a product would not know: - A claimant is not on the schedule until the retainer is signed, the ID check has a dated result and at least one piece of evidence of the kind this action requires is on file. - The questionnaire scores answers in a way settled with counsel, and a claimant who fails it may answer again once, after a call, and never a third time. - Two enquiries sharing a date of birth and a postcode are held as a possible duplicate until a person clears them, because the court's schedule cannot carry anyone twice. - Deductions from a settlement follow the order the retainer sets out, each capped as the retainer says, and the cap depends on when the claimant signed. None of it is written down anywhere but the site. ## The Old Guard: a Web Forms site from the first big action Built for the firm's first big action, somewhere between 2008 and 2013, by a contractor or a small agency, so the whole team could work in one place and claimants could sign up online. An ASP.NET Web Forms (https://www.solvewithsoftware.com/modernise/aspnet-web-forms) site on the .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) over SQL Server (https://www.solvewithsoftware.com/modernise/sql-server), with the nightly jobs as SQL Agent steps and a few console programs, and the exports as scheduled queries writing spreadsheets to a share. It runs on a Windows server in the firm's own server room, or in a rack at a local hosting company. The contractor's people scattered once the first action closed, and the folder of SQL scripts now belongs to one person who learned them by running them. Each action since has bolted on a questionnaire, a rule or a schedule format the court ordered, usually in the week before a deadline, with no design to fit it into. Every addition leaves the site a little stiffer to change. ## The New Legacy: the claimant portal an agency left behind The same system built between 2016 and 2022 for a newer action, by an agency or a freelancer, as a claimant portal and case screens in React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), PHP (https://www.solvewithsoftware.com/modernise/php) or .NET Core (https://www.solvewithsoftware.com/modernise/dotnet-core), or run as a claimant tracker in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) put together by someone in the operations team. From the claimant team's desks it looked finished: sign-up on a phone, a portal where claimants upload their evidence, a dashboard with the counts on it. A new action finds its limits first. The portal was shaped around one cohort's questionnaire and one court's schedule, so the next cohort brings questions and columns it has no place for, and the agency that could add them has moved on to other work. When one eligibility question went in against a deadline, a batch of claimants landed at the wrong stage, and the code has been left alone ever since. The hosting, meanwhile, sits in the name of someone who has left the firm. Since 2023 a few have been started in an AI app builder to catch a fast-moving action, then stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) before the schedule export worked. Each new cohort's extra questions now go out on a separate form, and a paralegal copies the answers into the portal claimant by claimant. ## Why does the firm depend on it? **A cohort in the tens of thousands carried through one process by a team that could never do it on paper.** The site is what lets a firm take on tens of thousands of claimants against a court timetable and know, on any day, how many have enquired, signed, been verified and made the schedule. Every stage writes to the same claimant record, so the schedule the court receives is the list the firm has, and the phone team can say in seconds whether a caller is a claimant and where they are up to. The funder's numbers come from the same place, each month, without a week of counting. And when the action settles, the payment goes out to thousands of people with the deductions the retainer sets and an audit trail on each one. Every action since the first has run on it, and the rules from each are still in there. ## Where the strain shows Systems like this do not stop. They strain, and the strain lands on the deadline. **Built for one action, now carrying ten.** A claimant screen written for a few thousand people holds tens of thousands, the nightly job that rebuilds the status counts runs into the working day, and the schedule export times out, so it is run in pieces. The team knows which hours to avoid. **No Web Forms on modern .NET, and a server with a date.** The site runs on the .NET Framework, which has no path forward for Web Forms, on a Windows Server 2016 that goes out of support in January 2027. The developers who know it are few, and the one who knows this site is booked by the day. **The court orders a format the site cannot produce.** Each new order asks for the schedule or the disclosure in a different shape: a column never stored, a date stored as text, a grouping the export cannot do. Neither generation can change an export without a developer, so the deliverable is built by hand in a spreadsheet against a date that will not move. **Sign-up still ends on paper.** The website takes the enquiry, but the retainer goes out as a PDF, comes back scanned and is matched to the claimant by a paralegal, and the ID check happens in another service whose result is typed back in. At a few hundred sign-ups a day, the matching queue is where claimants get lost. ## What comes out of modernising it? **The same claimant record, with the schedule coming out of a button and sign-up finishing on a phone.** **The schedule as a button.** The court's schedule and the disclosure export produced from the claimant record in the shape the current order asks for, with that shape kept in settings rather than in a spreadsheet built at midnight. The next order changes a setting, not a weekend. **Sign-up finished on the phone.** Questionnaire, retainer signature and the ID check in one flow the claimant completes on their phone, writing straight into the existing database. The matching queue empties. **A database that keeps up.** The claimant tables indexed for the queries the team runs, and the nightly rebuild replaced by counts kept as each record changes, so the status screen is right first thing and the export runs whole. **Off Windows Server 2016.** The site and the database on versions that are supported, with tens of thousands of people's personal data held the way the regulator expects. **Every claimant told, and the reply on the record.** Bulk email and text to a cohort from the system, with the bounce, the reply and the call on the claimant's record: the proof someone asks for later. **The funder's own view.** A login for the funder and the insurer with the numbers they ask for each month, from the same data, without a paralegal counting. The old site is not switched off for any of this. Each piece is added beside it, on the same data. ## How much of the claimant paperwork could AI carry? **Reading and cross-checking at volume, with a person confirming every result.** AI helps where the claimant numbers meet the paperwork, and stays out of the decisions. **Evidence read into the claimant record.** A claimant uploads a payslip, a statement or a photograph, and a paralegal types the employer, the dates and the amounts into the record. AI fills those fields from the upload and marks any it could not read, so the paralegal confirms rather than keys. At 200 sign-ups a day while a claim is advertised, two uploads each and three minutes' typing saved per upload, that comes to twenty hours a day, a couple of hours each for ten paralegals on the evidence queue. **Claimant emails sorted onto the right record.** The hundreds a day ask the same few things: has my form arrived, what stage am I at, when will I be paid. AI matches each email to its claimant, files it, and drafts the reply from the record for a case handler to read and send. Two hundred emails a day at two minutes saved on each works out at nearly seven hours a day across the case handlers who watch the inbox. **Sign-ups that may be one person twice, or no one at all.** Beyond the date of birth and postcode rule, AI looks for the same phone number, address or bank details under supposedly different claimants, or questionnaire answers pasted word for word, and queues each match for a person to clear or refer. Checked by hand at a minute each, 200 new sign-ups a day would take over three hours; a handful of queued matches at a minute each comes to a few minutes each morning. Not worth doing: letting AI decide a claimant's eligibility, strike out a suspect sign-up, or answer a question about the merits of a claim. The scoring was settled with counsel and a person applies it, advice on a claim is a lawyer's to give, and a model doing any of that would need explaining to the court. Each of these writes to the record the schedule is built from, so none starts before the first stage makes that record safe to change. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) shows where it would pay back on the site as it runs today. ## How the work is staged Safe to change first, then the piece the next deadline depends on, then the rest, and the old site stays as the fallback until the end. 1. **Stabilise.** The Web Forms source found and matched to the running site, the nightly jobs and the scripts collected and read, the database on a version still supported, a backup restored on purpose, and a test copy that treats the claimant data as the personal data it is. This goes first because the next court deadline will land on this system, and nothing gets changed under a deadline without a copy to try it on. 2. **The schedule and the exports.** The piece a deadline depends on comes first: the schedule and the disclosure produced beside the site from the existing database, in the shape the current order asks for. The site does not change. 3. **Sign-up on a phone.** Questionnaire, signature and ID check in one flow, writing into the same claimant record. The paper retainer stays for anyone who wants it. 4. **The claimant and cohort screens in a browser, bulk communication, the funder's view.** Each a stage, each priced on its own. 5. **Retire the Web Forms site** when nothing still depends on it; with the server date handled in the first stage, that can wait. Expect the settlement screen to go last, because accounts trust it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a claimant system that means a few days with the case handlers, the person who runs the scripts and the code, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a group litigation claimant system takeover What the assessment establishes on a claimant system, and why each item matters: | Check | Why it matters | |---|---| | Does the source match the running site, and where are the nightly jobs and the scripts? | Sites built for one action usually keep half their logic in SQL Agent jobs and a folder of scripts. Those are part of the system. | | How big are the claimant tables, and what runs slowest? | Volume is the pressure. The slowest query and the longest job set the order of the database work. | | Which Windows Server and which SQL Server, and where is the site hosted? | Windows Server 2016 support ends in January 2027, and a Web Forms site cannot be carried forward as it is. Both shape the first stage. | | How is a claimant identified across enquiry, sign-up, ID check and the schedule? | A claimant listed twice on a court schedule is the failure everyone fears. The matching rule is found and kept. | | Where do the eligibility and cohort rules live? | The scoring settled with counsel may be in code, in a stored procedure or in a spreadsheet beside the system. It has to be found before any screen changes. | | What exports does the current order require, and what produces them today? | The schedule format is the deliverable. Whatever builds it now, however manual, is the specification. | | How do bulk letters and emails go out, and where is the record that they did? | Proof that every claimant was told gets asked for later. A mail merge from a spreadsheet leaves no record. | | What personal data is held, who can see it, and how is a subject access request answered? | Tens of thousands of people's data, some of it medical or financial, and a subject access request has to be answerable from it. That sets the hosting and who sees what. | ## Questions Q: We have a schedule due to the court soon. Can anything change before then? A: Yes, and the order of the work is chosen for that. The first stage makes the system safe to change, and the first new piece is the schedule itself, built beside the site from the same data, so the next deadline is met from a button rather than a spreadsheet. Nothing about the site the team uses every day changes until after it. Q: Is there an off-the-shelf system that does this? A: There are litigation and case management products, and the assessment says whether one fits. Systems like this usually hold rules a product does not: the questionnaire scoring settled with counsel, the duplicate rule, the deduction order from the retainer. Those are the reason the firm built its own, and they are the first thing the assessment finds and writes down. Q: Do the claimants have to sign up again? A: No. The new sign-up flow writes into the same claimant record, so everyone already on the books stays where they are. Only new claimants, and anyone who never finished, go through the new flow. Q: What about the claimants' personal data during the work? A: It stays where it is, and the test copy used for changes is handled as personal data too, with access limited to the people who need it and the copy destroyed when the stage ends. The assessment records what is held and who can see it, which is also the answer the firm needs for its own data protection file. --- # The system that rates and reports your specialist schemes URL: https://www.solvewithsoftware.com/systems/professional-services/insurance-broker-scheme-system Title: Insurance Scheme System Modernisation Description: A specialist broker's own scheme rating, policy and bordereaux system, what modernising it brings, and where AI helps first. From £395 + VAT. Last reviewed: 2026-09-14 An insurance broker's scheme system is where its specialist schemes live: the rating tables, the referral rules, the policies, the renewals and the bordereau each insurer expects every month. Solve With Software takes over scheme systems built for a broker's own schemes, keeps them running, and modernises them in stages, so the quote team keeps the screens it knows while the rates become tables the office can change and each bordereau comes straight from the policy records. AI helps first with the proposal forms and introducers' emails, reading each into a draft quote for a handler to check. The assessment prices each stage before you commit. The Old Guard: Written 2002 to 2013 by a contractor who knew the scheme, in VB6 or Access over SQL Server, with a Web Forms quote form for introducers. The New Legacy: Built 2016 to 2022 by an agency or freelancer as an online quote-and-buy in PHP or React, or in Bubble; since 2023, sometimes begun in an AI builder. Where AI helps: Proposal forms read into draft quotes: about 30 a day at five minutes' typing each comes to two and a half hours a day across the quote team. ## Rating, binding and the month-end bordereau A typical business running one of these has 20 to 120 staff, a handful of specialist schemes (motor trade, taxis, holiday lets, specialist contractors, classic vehicles) and a few hundred to a few thousand policies a month, quoted and renewed by the phone team, introducers and a web quote form. Those are composite figures. Most brokers put their open-market business through a bought broking platform. This page is about the system beside it, written for the schemes the platform cannot rate, and most common at specialist brokers and managing general agents writing under delegated authority from one or two insurers. Written in 2006 or in 2020, it does the same job. In the scheme manager's words, it rates each risk from the scheme's tables with its loadings and discounts, refers what falls outside the binding authority to the insurer's underwriter, issues the schedule and certificate, handles mid-term changes, cancellations and renewals, takes the premium or the instalments, works out the insurance premium tax and commission, and builds each insurer's bordereau at the month end, with claims where the broker handles them. The rules in it belong to the schemes: - A risk with recent claims, a value above the scheme's limit or a postcode in a band the insurer watches goes to the insurer's underwriter, and the office cannot bind it. - New rates apply only to quotes from their effective date, and an issued quote keeps its rates until it expires. - A mid-term change is charged or refunded pro rata to the day, with the premium tax worked out again on the difference. - Each insurer sets its own bordereau columns, codes and cut-off, and a policy bound after the cut-off goes on next month's. - A renewal on a retail home or motor scheme may not be priced above what the same customer would be quoted as new business. ## The Old Guard: a contractor's rating program from around 2005 Written somewhere between 2002 and 2013 by a contractor who understood the first scheme, then grown one scheme at a time. The quote and policy screens are a Windows program in Visual Basic 6 (https://www.solvewithsoftware.com/modernise/vb6) or a Microsoft Access (https://www.solvewithsoftware.com/modernise/microsoft-access) database, the data sits in SQL Server (https://www.solvewithsoftware.com/modernise/sql-server), and the schedule and certificate merge into Word templates. Between 2010 and 2013 the introducers were given a quote form of their own, an ASP.NET Web Forms (https://www.solvewithsoftware.com/modernise/aspnet-web-forms) site on the .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework) reading the same database. The bordereau is a query pasted into Excel on the last working day and reshaped by hand for each insurer. All of it runs on a server in the office. The contractor has since retired or moved on, and the rates for each scheme ended up split between tables in the database and figures typed into the code. When the insurer agrees new rates, someone edits the tables, runs a handful of test quotes against last year's prices, and trusts the code has nothing else to add. ## The New Legacy: online quote-and-buy, built around 2019 The same scheme system built between 2016 and 2022, usually because the broker wanted customers to buy a policy without ringing. A small agency or a freelancer wrote it in PHP (https://www.solvewithsoftware.com/modernise/php) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), or someone put it together in Bubble (https://www.solvewithsoftware.com/rescue/bubble). From the office it looked as though the schemes had caught up: a customer gets a price late at night, pays by card or signs up for instalments, and has the schedule and certificate by email before the phone team is in. The rates are what pin it down. The rating tables were written into the quote journey's code, so every rate change the insurer agrees joins a developer's queue, and new rates can go live after the date they were meant to start. Then one insurer changed its bordereau format, the export stopped matching the columns it now expects, and the month end went back to a spreadsheet. Since 2023 some brokers have tried again in an AI app builder, and the attempt stalled (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) at the referral rules. These days the scheme manager asks each insurer for new rates to start a month or more out, to give the developer time. ## Why do the schemes still run on it? **It prices a specialist risk on the call, inside the authority the insurer granted, and reports every policy to the insurer that carries it.** A specialist scheme is priced on questions a general platform does not ask, and the scheme system holds those questions and the rates behind them. A new handler quotes a risk the way the scheme manager would, and the office writes the business the insurer has given it authority for without phoning the underwriter each time. The referral rules protect that authority: what should go to the underwriter does, and the rest binds while the customer is still on the line. The money is the other half. Premium, tax, commission and instalments are worked out once, on the policy, and the bordereau is built from the same records, so what the insurer receives matches what was sold. The renewal run picks up each month's renewals without anyone keeping a diary. ## Where the schemes have outgrown it The quoting still works. The pressure comes from the regulator, the insurer and the server cupboard. **The Consumer Duty wants outcomes it never recorded.** The FCA's Consumer Duty has applied to open products since 31 July 2023 and to closed books since 31 July 2024, and it asks for fair value and good customer outcomes to be evidenced, with an annual assessment by the board. Old program or agency build, the system holds the policy and the premium but nothing on cancellations, claims, complaints or renewal retention by customer group, so the evidence is pieced together from exports. **The auditor asks for history the system overwrote.** The insurer audits the delegated authority and asks which version of the rates priced a given policy, and what became of each referral. The old tables were replaced when the new rates went in, and the referrals are in someone's inbox. **The bordereau is late, or it comes back.** Each insurer's file is built from a query and a spreadsheet in the last days of the month, and a rejected row means finding the policy behind it and sending the file again. Late and rejected bordereaux are a standing item between broker and insurer. **The server has an end date.** Often that is Windows Server 2016 over a SQL Server 2016 database. SQL Server 2016 stopped receiving updates in July 2026, Windows Server 2016 follows in January 2027, and any still on Windows Server 2012 have been without support since October 2023. ## What would modernising the scheme system change? **The same schemes and screens, with rates the office can change, a trail the auditor can follow, and bordereaux built from the policies.** **Rates the scheme manager loads.** Each scheme's tables come out of the code as versions with an effective date, loaded by the office and tried on test quotes before the date arrives. Every quote records the version that priced it and keeps it until it expires. **One price, however the risk arrives.** The phone team, the introducers and the web quote read the same tables, so a rate change reaches all three on its date. **Referrals on the record.** The trigger, the underwriter's answer and the name of whoever bound the policy, kept against the quote. The next audit gets its referral log from a report. **Bordereaux at the cut-off.** Each insurer's columns, codes and cut-off are held as settings, and the file is produced from the policy records and checked against that insurer's rules before it is sent. A new format is an edit to a setting. **Outcomes kept against each policy.** Cancellations, claims, complaints and renewals recorded by scheme and customer group, so the fair value review and the board's annual assessment start from a report. **Off the 2016 server.** The database on a version still supported, on a server that is too, with a backup that has been restored on purpose. Nothing here needs the old program or the agency's site turned off. Each piece goes in beside it, on the policies already there. ## What could AI read for the quote team and the month end? **The reading and matching around each quote and bordereau, with a person deciding any price or referral.** **Proposal forms read into draft quotes.** An introducer emails a proposal form, a schedule of vehicles or a few paragraphs about the risk, and a handler types it in. AI fills in a draft quote from it, marking any answer it could not find, for the handler to check and rate. At about 30 emailed submissions a day and five minutes' typing saved on each, that comes to two and a half hours a day across the quote team. **Bordereau rejections traced to the rows.** The insurer's rejection report lists the rows that failed and why. AI matches each one to the policy behind it and drafts the fix, a missing postcode or a tax figure a penny out, for whoever builds the bordereau to approve. If 60 rows come back from a file of a few hundred to a few thousand, tracing and fixing each at seven or eight minutes adds up to a working day of lookups; approving the drafted fixes at a minute apiece takes an hour. **Quotes whose answers moved.** A re-quote where the declared claims dropped after a high price, or a mid-term change that moves the postcode into a cheaper band, is flagged for a person to review; AI decides nothing. At about 30 re-quotes and mid-term changes a day, comparing each with its earlier answers by hand would take half an hour at a minute apiece; five or so flags at three minutes each come to a quarter of an hour each morning. **The book asked questions in plain words.** "Which renewals next month had a claim this year?" "Which scheme loses the most policies in the first month?" AI answers from the policy records, which it can read and not alter, and lists every policy it counted. Three or four such questions a week, at half an hour to write and check each query, comes to an hour and a half to two hours a week for whoever writes them. Not worth doing: AI setting rates or deciding a referral. The rates are agreed with the insurer and the referral belongs to its underwriter under the binding authority. Each reads the policy records or drafts into them, so none starts before the first stage makes the scheme system safe to change. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back on the broker's own schemes. ## The order of the work, with the old system still quoting Safe to change first, then the rates, then the month end, with the old system quoting throughout. 1. **Stabilise.** The VB6 project, the database file, the Web Forms site or the agency's code found and matched to what the office runs, the database on a version still supported, a backup restored on purpose, and a test copy that can rate a quote without binding anything. This goes first because every rate change the insurer agrees passes through this system, and because Windows Server 2016 support ends in January 2027. 2. **The rating tables.** Each scheme's rates come out of the code into versioned tables, and a sample of recent quotes is rated both ways until the prices agree. The screens do not change. 3. **The bordereaux.** Each insurer's file produced from the policy records in its own format, run beside the spreadsheet until the insurer accepts it first time. 4. **The referral log, the outcome data, the quote screens in a browser.** Each a stage, each priced on its own. 5. **Retire the old program** when nothing still depends on it. The renewal run usually goes last, because the whole book passes through it. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a scheme system that means a few days with the scheme manager, the accounts team and the code, finding the rates, the referral rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for an insurance broker scheme system takeover What the assessment establishes on a scheme system, and why each item matters: | Check | Why it matters | |---|---| | Is the source available for the Windows program, the Web Forms quote form or the agency's build, and does it match what runs? | One contractor or one agency usually wrote it. Without the source it can be kept running but not changed, and a rate change is a change. | | Where do the rating tables live, and are past versions kept? | Rates split between tables and code make every rate change a developer's job. Without past versions, nobody can show the insurer's auditor how an old policy was priced. | | How are referrals triggered, and where is the underwriter's answer recorded? | The triggers are the binding authority written as code. They are found, set against the agreement and written down before anything moves. | | How is a home or motor renewal priced against new business? | The FCA has banned price walking on home and motor renewals since 1 January 2022. Whatever holds a renewal to the equivalent new business price has to survive every stage. | | How is each bordereau built today, and what did the last rejection report say? | The query, the spreadsheet steps and the rejections are the specification for each insurer's format. | | How are pro rata adjustments, premium tax, commission and instalments worked out? | These are the figures the insurer is paid and the broker earns. They are tested against past policies to the penny before anything replaces them. | | Which Windows Server and SQL Server, and when was a backup last restored? | SQL Server 2016 updates ended in July 2026, Windows Server 2016 ends in January 2027 and Windows Server 2012 ended in October 2023. A backup nobody has restored is untested. | | What customer and outcome data is held, and who can see it? | Proposals carry claims and convictions history, which is personal data to protect. The Consumer Duty assessment needs cancellations, claims, complaints and retention by customer group, and what exists now sets what can be reported. | ## Questions Q: Can we keep quoting and renewing while the system is modernised? A: Yes. The old program or the agency's site keeps rating and binding throughout, and each new piece is built beside it on the same policy records. The phone team moves to a new screen once it gives the same price for the same risk, and not before. Q: Will our rates and referral rules come across exactly as the insurer agreed them? A: They are the first thing found. The rating tables, loadings and referral triggers are read out of the code and the database, written down with the scheme manager, and checked by rating a sample of recent quotes both ways until every price agrees. Where the rules in the system and the binding authority disagree, the assessment says so. Q: Each insurer wants its bordereau in a different format. Can that be handled? A: Yes. Each insurer's columns, codes and cut-off are kept as settings rather than in a spreadsheet, so a new format is an edit to the settings instead of a developer's job. The file is checked against that insurer's rules before it is sent, so a missing field is found in the office first. Q: Can it give us the outcome data for our Consumer Duty assessment? A: From the stage that starts recording it, yes: cancellations, claims, complaints and renewals by scheme and customer group, reported for the board's annual assessment. For earlier years the assessment checks what the policy records already hold, such as cancellation dates and renewal history. --- # The timesheet and pay-and-bill system behind your weekly pay run URL: https://www.solvewithsoftware.com/systems/professional-services/recruitment-timesheet-payroll-system Title: Recruitment Pay-and-Bill Modernisation Description: A temp agency's own timesheet and pay-and-bill system: weekly pay, client invoices, what modernising it brings and where AI helps. From £395 + VAT. Last reviewed: 2026-09-14 A recruitment timesheet and pay-and-bill system is what a temporary staffing agency runs beside its bought candidate database: every assignment's pay and charge rates, the week's timesheets and their authorisation, the weekly pay run and the client invoices that come from the same hours. Solve With Software takes over systems like these, keeps them running, and modernises them in stages, so the payroll team keeps the rules it trusts while the agency gets authorisation from every client, a record behind every umbrella payment, and screens that open at every branch. AI helps first with the timesheets that arrive as photos, PDFs and spreadsheets, reading each one onto its assignment for the payroll team to approve. The assessment prices each stage before you commit. The Old Guard: Written 2005 to 2013 by a contractor as a Windows pay-and-bill program on the .NET Framework and SQL Server, with Crystal payslips, on the office server. The New Legacy: Built 2016 to 2022 by an agency or freelancer as a timesheet portal with a temps' app, or in Power Apps or Bubble; since 2023, sometimes tried in an AI builder. Where AI helps: Photo, PDF and spreadsheet timesheets read onto assignments: 100 to 670 a week at a minute and a half's keying each comes to a morning to about two days. ## What the payroll team does in it each week Monday's timesheets become the week's pay and the week's invoices. A typical business running one of these has 20 to 100 internal staff across one to four branches, between 300 and 2,000 temporary workers on assignment in any week in industrial, driving, warehouse, care or office roles, and a payroll team of two to five running a weekly pay run and weekly client invoicing. Almost every agency this size runs a bought candidate and client database. This page is about the system beside it, the one the agency had built for itself, which takes over once a temp is placed. Written in 2009 or in 2020, it runs the same week. In the payroll team's words, it holds each assignment with its pay rate and charge rate, takes in the timesheets however they come (paper, emailed spreadsheets, a client portal's export, the temps' app), gets each one authorised by the client, and applies the overtime, night and weekend rates from that client's contract. It pays PAYE temps, umbrella companies and limited company contractors, invoices each client with the timesheet behind every line, tracks holiday pay and each worker's weeks in the same role under the Agency Workers Regulations, and reports margin by client. The rules it applies belong to the agency: - A pay rate never changes without its charge rate. - Nobody is paid without a client-authorised timesheet, except at the named clients who authorise the week by email. - A worker reaching 12 weeks in the same role with the same hirer moves to the comparable rate the client has confirmed, with the count following the regulations' rules on breaks. - Holiday pay is rolled up at 12.07% only for workers classed as irregular hours or part-year; everyone else accrues it and is paid when they take leave. - Pay below the legal minimum for the worker's age stops the pay run. ## The Old Guard: the contractor's pay-and-bill program The first version arrived somewhere between 2005 and 2013, when the agency paid a contractor to write it a Windows pay-and-bill program on the .NET Framework (https://www.solvewithsoftware.com/modernise/dotnet-framework). The data is in SQL Server (https://www.solvewithsoftware.com/modernise/sql-server), the payslips, remittances and client invoices come out of Crystal Reports (https://www.solvewithsoftware.com/modernise/crystal-reports), and the clients' timesheet spreadsheets are pulled in by an Excel import (https://www.solvewithsoftware.com/modernise/excel-to-system) that expects its columns in a fixed order. It lives on the server in the head office and is installed on the payroll team's desks. The contractor stopped taking calls years ago, and the only changes since are the ones payroll could make in a settings table. A branch manager who wants to see a timesheet phones head office. Each year's new minimum wage rates go in by hand, and nobody is sure which other tables should have changed with them. ## The New Legacy: the portal, the app and the Monday spreadsheets Between 2016 and 2022 other agencies had the same system built for the browser, around the two things the old program never had: a timesheet portal for clients and an app for the temps. A small agency or a freelancer wrote it in PHP (https://www.solvewithsoftware.com/modernise/php) or React, Angular or Node (https://www.solvewithsoftware.com/modernise/react-angular-node), with the app in React Native (https://www.solvewithsoftware.com/modernise/react-native), or someone in operations put it together in Power Apps (https://www.solvewithsoftware.com/rescue/power-apps) or Bubble (https://www.solvewithsoftware.com/rescue/bubble). From the payroll desk it looks like the future: hours entered on a phone, approved from a link, each client seeing its own week. Client authorisation is what stranded it. The portal worked for the clients willing to log in; the rest still email spreadsheets, keyed on Monday by the payroll team the portal was meant to spare. When rolled-up holiday pay was allowed for irregular hours and part-year workers in 2024, the change was patched into the pay screen and never reached the invoice template, so some clients are still charged the old way and the margin report cannot say by how much. The freelancer behind the rate logic has moved on. Since 2023 a few agencies have tried the timesheet side again in an AI app builder, and those attempts (https://www.solvewithsoftware.com/problems/stalled-ai-built-app) tend to stop at the first client whose overtime rule does not fit the form. ## Why does the agency trust it with the pay run? **Up to two thousand people paid each week by a payroll team of a few, with every paid hour billed to the client who authorised it.** The pairing of pay and charge is what the agency lives on. Every assignment carries both rates, and every authorised timesheet produces a pay line and an invoice line together, so an hour cannot be paid and left off the invoice. The margin on each client is known the week it is earned. A pay line under the minimum never leaves the building, the 12-week count brings in the comparable rate on the week it is due, and holiday pay follows each worker's classification instead of whoever happened to key the timesheet. When a client queries a line, payroll opens the timesheet and the authorisation behind it, and the query usually ends there. Every client's overtime arrangement and every exception agreed over the years is already in it, which is why the agency still runs the week on it. ## Where the pay run has started to creak The pressure on systems like this mostly comes from outside the payroll office. **Umbrella pay is now the agency's to answer for.** From 6 April 2026 the recruitment agency supplying a worker through an umbrella company is responsible for PAYE on that worker, and jointly and severally liable if the umbrella fails to pay. Whichever generation built it, the system records the payment to the umbrella and nothing about what the umbrella then paid, so any checking happens in a spreadsheet beside it. **The client's decision on a contractor has nowhere to go.** Since April 2021, medium and large private sector clients have decided whether each limited company contractor falls inside the off-payroll working rules. The assignment screen knows the contractor is a limited company and nothing more, so the decisions sit in an email folder. **The server and the database both have dates.** Where the program runs on Windows Server 2016 over a SQL Server 2016 database, the database lost its updates in July 2026 and the server loses its own in January 2027. Moving a payroll database needs a week with no pay run in it, and an agency that pays weekly never has one. **A new client means a new spreadsheet layout.** Each client's timesheet export has its own columns, and the import only knows the layouts the agency had when it was written. A new client's sheet gets retyped, or reshaped by hand into an old client's layout, every week. ## What would modernising it give the payroll team? **The same rates and rules, open at every branch, with the umbrella and contractor records the agency now has to keep.** **Every client's timesheet in, whatever the layout.** Each client's spreadsheet layout is mapped once and kept in settings, so a new client or a moved column stops meaning weeks of retyping. The portal, the weekly authorisation email and the temps' app all land on the same assignment. **A record behind every umbrella payment.** What each umbrella received, what it reported paying the worker and HMRC, and which umbrellas have not sent their figures, held on the assignment beside the payment. **The client's decision on each contractor.** The off-payroll decision on the assignment with its date and document, and a contractor placed inside the rules held back from being paid without PAYE. **Invoices that follow the pay rules.** Holiday pay, the 12-week comparable rate and the overtime multipliers set once for both sides, so a change to pay reaches the invoice that week and the margin report can be trusted. **Pay and bill from any branch.** The same screens in a browser at every branch and from home, one login each, so a branch manager looks up a timesheet instead of phoning head office. **Off the 2016 servers.** The database on a version that still receives updates, on a server that does too, with a backup restored to prove it. **The rules where payroll can read them.** The authorisation exceptions, the minimum wage check and each client's multipliers out of the code and into settings, written down with the people who apply them. The old program keeps paying people while each piece goes in beside it, and nothing is switched off until its replacement has matched a pay run. ## Which parts of the pay week could AI carry? **The keying on Monday, the checking before the pay run goes, and the questions no report was written to answer.** **Timesheets read onto their assignments.** A photographed paper sheet, a PDF from a site supervisor, a client's spreadsheet in an unmapped layout: AI reads each one, matches names and dates to live assignments and drafts the hours, marking what it could not read, for payroll to approve. When a third of 300 to 2,000 weekly timesheets arrive like that, about 100 to 670, keying them at a minute and a half each comes to anything from a morning to about two days' typing a week, and checking the drafts hands most of it back. **The pay run checked before it goes.** AI reads every pay line against its assignment and the worker's recent weeks and lists the ones that look wrong: hours over a limit, a charge rate below the pay rate, one worker paid twice across two branches, a week unlike any that worker has had. A person clears each flag. Reading 300 to 2,000 pay lines by eye at ten seconds a line works out at between about an hour and five and a half hours; fifteen or so flags at two minutes each take half an hour to clear. **Questions asked of the assignments.** Which workers reach week 12 with their hirer next month? Which clients have timesheets still unauthorised after a week? AI answers from the assignment and timesheet records, read-only, and lists every record it counted, so the branch manager checks names rather than trusting a total. Setting one report against another by hand for 500 live assignments, at half a minute a line, adds up to about four hours, the afternoon a month those answers replace. Not worth doing: AI deciding whether a contractor falls inside the off-payroll rules, or choosing which temp gets a shift. The first is the client's decision to make and to explain; the second is a consultant's judgement of people, and a model could not say why it chose. Each of these reads or writes the records the pay run depends on, so none goes live before those records can be changed on a copy. The assessment (https://www.solvewithsoftware.com/legacy-system-assessment) maps where AI would pay back soonest on the agency's own pay week. ## How the stages fit around a weekly pay run Safe to change first, then the records the law now asks for, then the timesheets, with the old program paying people until each new piece matches it. 1. **Stabilise.** The source code found and matched to the running program, or the portal's code and hosting recovered, the database on a version still receiving updates, a backup restored, and a test copy where a past pay run can be repeated. This goes first because nothing that pays people is changed without a copy to try it on, and because Windows Server 2016 support ends in January 2027. 2. **Umbrella and contractor records.** The umbrella payment record and the client's off-payroll decision beside the pay run, on the existing database, with the pay run unchanged. The liability has been live since April 2026. 3. **Timesheets from every client.** The spreadsheet layouts mapped, portal and email authorisation landing in one place, and the temps' app released again. 4. **Pay-and-bill screens in a browser, invoices from the same rules, the margin report.** Each priced before it starts, and run beside the old pay run until the totals agree. 5. **Retire the old program** once nothing leans on it. Expect the payslip to go last, because the temps know what theirs looks like. The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a pay-and-bill system that means a few days with the payroll team, a branch manager and the code, following each rate from the assignment to the payslip and the invoice, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work (https://www.solvewithsoftware.com/how-we-work), what drives the price (https://www.solvewithsoftware.com/legacy-system-modernisation-cost) and the payment terms (https://www.solvewithsoftware.com/pricing) each have a page. ## The technical checklist for a recruitment pay-and-bill system takeover What the assessment settles on a pay-and-bill system, and why each item matters: | Check | Why it matters | |---|---| | Is the source code available, and does it match the program payroll runs each week? | A contractor-written program may exist only as the copy installed on the payroll desks. Without its source it can be kept running, but every rule in it stays frozen. | | Where do the pay rates, charge rates, overtime multipliers and holiday pay classifications live? | Rates held in code turn every new client contract into a developer job. They are found and written down before anything moves. | | How does the system count weeks towards the 12-week comparable rate, and what does it do with breaks? | The regulations set the rules on breaks. The count the system keeps is tested against past assignment histories before it is relied on anywhere new. | | What does the system hold about umbrella companies and limited company contractors? | Since 6 April 2026 the agency is responsible for PAYE on workers paid through umbrella companies. What is held today decides what the first new screen has to add. | | Which SQL Server and Windows Server, and who last restored a backup? | Updates for SQL Server 2016 ended in July 2026, and Windows Server 2016 support ends in January 2027. A payroll database is the last place to find out a backup does not restore. | | How do timesheets arrive from each client, and which imports break when a layout changes? | Each client's layout is a small specification. The ones keyed by hand show where the payroll week goes. | | Does the system calculate PAYE itself or pass gross pay to a payroll package, and how do invoices reach clients? | The pay run and the invoices are the links the agency cannot lose. Electronic invoicing is due to become mandatory for business-to-business VAT invoices from April 2029, so the invoice route is checked against that too. | | What personal data is held on each worker, and who can see it? | Bank details and National Insurance numbers for hundreds or thousands of people. The answer shapes the hosting, the access rules and the test copy. | ## Questions Q: Will the pay run still go out every week while this happens? A: Yes. The old program pays people every week until each new piece has produced the same totals on a past week. Nothing takes over a step of the pay run until it has matched the old one. Q: Every client has its own overtime and holiday pay arrangement. Do those survive? A: They are the first thing looked for, in the code and in the settings tables, and they get written down with the payroll team who apply them. They then go into settings payroll can read, and pay and charge are both worked out from the same place, so the invoice cannot drift from the payslip. Q: Can the system show what our umbrella companies have paid? A: It can be made to hold it. Since 6 April 2026 the agency supplying the worker is responsible for PAYE on workers paid through umbrella companies. What the checks on each umbrella should be is for the agency and its advisers to decide; the system's part is to hold the evidence against each payment, week by week. Q: Do the temps and the clients have to change how they send timesheets? A: No. The routes in use today keep working, and new ones are added beside them. A client who sends a spreadsheet every Monday can carry on sending it, and a temp who fills in paper can too. Q: When can it start, given we pay every week? A: Around the pay weeks. Every stage is planned so that nothing changes on a pay day, and the busy season can be left alone entirely, with the stages before and after it. The first stage touches only a copy of the data, so it can start in any week. ---