Sage 300 on a private cloud
Your usual Sage 300 screens, in a browser, from any office or from home. Month-end reports that used to take 45 minutes finish in under 3. We host it, back it up and support it for one monthly fee.
Month-end, before and after the move
What changed for one client when Sage 300 moved from a generic cloud server to ours.
Report timings from an anonymised client environment (see the field note below). The other rows describe the platform design.
Why Sage 300 feels slow, and what we change
Sage 300 sends a lot of small requests to its database. On a generic cloud server, or over a VPN from a branch, each one waits a little, and the waits add up to the slow screens and long reports most users simply put up with.
We fix it where it starts. Your database sits on fast dedicated storage next to the Sage application, SQL Server is set up for the way Sage 300 uses its tables, and users connect through a browser stream instead of pulling data over a VPN.
What you get
Each item is part of the standard service, not an add-on.
Browser access
Staff open Sage 300 in a browser tab from the office, home or a branch. There is no VPN to set up and nothing to install on laptops.
Fast storage
NVMe solid-state drives, several times faster than the shared disks most servers use. Storage speed decides how long a Sage 300 report takes.
A region near you
Data centres in the Middle East, Asia and Europe. You pick the region, and your data stays in it.
Database tuning
SQL Server is configured and maintained for the way Sage 300 stores its data, including the index upkeep that office servers often skip.
Backups that can't be altered
Backups are locked once written, so ransomware can't encrypt or delete them. They run often enough that at most five minutes of work is ever at risk.
Your own servers
Your Sage 300 runs on servers used only by your company, with multi-factor sign-in for every user.
Field note, anonymised
"Month-end reports that took 45 minutes now complete in under 3. That alone justified the move. We also stopped worrying about the backups, because we can see them run and we know they can't be deleted."
The server behind it
Starting specification for a typical Sage 300 company, in line with Sage's own sizing guidance. The assessment sizes yours.
Fast solid-state drives. Reports stop waiting on the disk.
Enough headroom for month-end with everyone logged in.
Error-correcting memory, the kind used in servers that can't afford silent faults.
The link between Sage and its database is never the bottleneck.
How the move works
Your users keep working until the last evening.
Moving Sage 300 to our cloud is planned so the old system stays in use while the new one is built and tested. The only pause is the final data sync, which we schedule outside working hours.
The old server stays untouched after go-live, so there is always a way back.
The full migration plan- 01
Assessment
We look at the system you run today: database size, user count, branches, integrations, scheduled jobs, the reports that run slowly and your backup history. You get a sizing, a fixed monthly price and a dated move plan.
- 02
Build the new environment
We build your servers in our cloud alongside the old one. Nothing changes for your users while this happens.
- 03
Trial move
We restore a recent copy of your data into the new environment and your key users test it: reports, printing, integrations and a month-end run. Anything that behaves differently is fixed here, not on go-live night.
- 04
Final sync
In an agreed out-of-hours window, usually a Friday night or a weekend, users log off, we move the latest data across and reconcile balances, open orders and stock.
- 05
Go live
Users log in to the new environment on the next working day. The old server is left untouched for an agreed period, so there is a way back if something unexpected shows up.
- 06
Hypercare
We watch performance and tickets closely for the first weeks and through the first month-end close, then hand over to normal support.
Questions we get asked
Sage 300 cloud questions
What do the 5-minute and 15-minute figures mean?
The 5 minutes is your recovery point: backups run often enough that, in a serious failure, at most the last five minutes of work would need re-entering. The 15 minutes is the recovery target for bringing the environment back from disaster recovery. Larger databases can take longer to restore, and we state the figure for your system in the proposal.
What does the 99.9% uptime SLA cover?
Availability of your hosted servers and the connection into them, measured monthly and excluding maintenance windows agreed with you in advance. 99.9% allows roughly 43 minutes of unplanned downtime in a month. Maintenance is scheduled outside your working hours.
Do we still own our Sage licences and our data?
Yes. Your Sage licences stay yours, and so does your data. If you ever leave, we hand back a full database backup and help the next provider or your own IT team restore it.
What happens if our office internet goes down?
The system keeps running in the data centre, so nothing is lost. Users who still have a connection, for example staff at home, another branch or on a phone hotspot, can keep working. We recommend a backup internet line for offices that depend on Sage all day.
Will printing, scanning and Excel exports still work?
Yes. Printing goes to your local printers, and exports download to the user's own machine. We test printing and your key exports during the trial move, before anyone depends on them.
Can we keep our customisations and integrations?
In most cases, yes. Customisations, add-ons and integrations move with the system. The assessment lists anything that needs a change, such as an integration that connects to a local file share, and we fix it before go-live.