Infrastructure for ERP, SQL and remote work

In our experience yes, and we prefer to have them in the conversation from the start. The vendor usually cares about the environment meeting their requirements, not about which building the server stands in. We share the planned specification with them, agree who does what during the migration window and who to call if something behaves oddly on the first working day. If your contract with the vendor names a specific setup, tell us early and we build to it rather than around it.

That comes out of the survey, not out of a price list. The numbers that matter are the size of the database today and how fast it grew over the last two years, how many people are logged in at the same time, whether reporting and closing periods create heavy peaks, and which integrations run in the background. A system used by eight accountants is a very different machine from one where forty people also work in a warehouse module. We size for the peak you actually have, with headroom to grow, and we would rather tell you the current server is enough than sell a bigger one.

Express is free and fits small installations, but it has limits on database size, memory and CPU use that a growing company eventually hits, usually at the worst possible moment. Standard removes those limits and supports proper scheduled backup jobs. We check what your system uses now and where the ceiling is, then say plainly which edition we recommend and what it costs. If Express still fits, we say so.

Not usually, and mixing the two is how migrations go wrong. Moving to new hardware and upgrading the application are separate projects with separate risks, so we prefer to move the system as it is, let it run for a while, and only then talk about the version. There are exceptions: if your current version will not install on a supported operating system, or the vendor has stopped patching it, then the upgrade has to be part of the plan and we say that at the survey rather than halfway through.

Separately from the file backups, on their own schedule, because a database copied as a file while it is running is often not restorable. We use the database engine's own backup mechanism, keep the copies off the machine that made them, and test a restore into a scratch environment so the procedure is proven rather than assumed. How often depends on how much work you are willing to redo: for most accounting systems the honest answer is a nightly full copy plus transaction logs during the working day.

That is a sizing question, not a licensing limit: you buy a CAL for each person or device, and the server has to have the memory and CPU to carry them. A rough planning figure for office work is somewhere around one to two gigabytes of RAM per active session, more when people keep large spreadsheets or a browser with thirty tabs open. We size from your real user count with headroom, watch it after launch, and add resources if the numbers say so rather than guessing upward from the start.