Business applications on Amazon Web Services
We look after business applications hosted on AWS, from Windows and SQL Server on EC2 to static sites, email and serverless tools, and move older systems onto AWS in planned stages.
What you probably want to know first
- Our application was moved to AWS years ago and nobody looks after the servers. Can you take that on?
- Yes. We start by listing what is running, who has access, how it is backed up and which Windows and SQL Server versions are in use, then put patching, backups and monitoring on a regular footing. Access is tightened as part of that, usually before anything else changes.
- Will you need full access to our AWS account?
- No. We ask for the access the work needs, through roles in your account that you control and can remove. The account, the billing and the data stay yours.
- Can AWS costs be reduced?
- Often. Common savings come from servers sized for a peak that never arrives, test environments left running, and storage nobody has reviewed. We show the saving for each change and make them one at a time.
- What have you done with systems like this?
- We moved Logtek's asset management application to the cloud and look after its AWS estate, including a move from SQL Server 2017 to SQL Server 2022 in 2026 and a separate staging environment that matches production. The Logtek case study describes it.
Who this page is for
This page is for IT managers whose business application is hosted on Amazon Web Services, often moved there by a previous supplier, and who need someone to own the servers, the database and the releases, not just the code.
What tends to go wrong
An application lifted onto AWS a few years ago usually still runs, which is why its hosting gets forgotten. The problems build up quietly:
- Versions age. Windows Server and SQL Server on the instances pass their end-of-support dates.
- There is nowhere to test. Changes go straight to production because no environment matches it.
- Access sprawls. Former staff and suppliers still have keys, and management ports are open to the internet.
- Backups are assumed. Snapshots exist, but nobody has restored one.
- Cost drifts. Instances sized for a launch peak keep running at that size.
How we approach it
We treat the hosting as part of the system. The first job is an inventory and a tested restore, so we know what we are looking after and that it can be recovered. Then access is tightened, a staging environment is built where changes are rehearsed, and upgrades are planned against the vendors’ end-of-support dates rather than discovered after them.
For Logtek, that meant rebuilding a staging environment that faithfully matches production, upgrading the production database from SQL Server 2017 to SQL Server 2022 after rehearsing it there, and moving the company’s public website off the application server onto S3 and CloudFront, so the application server no longer serves public web traffic.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss your AWS-hosted system 0800 433 7990What we do on AWS
- Windows and SQL Server on EC2
- Patching, upgrades, sizing and backups for the servers your application runs on.
- A staging environment that matches production
- A separate copy of the environment where every change and upgrade is rehearsed first.
- Backups you have restored
- Snapshots and database backups on a schedule, with restores tested rather than assumed.
- Access under control
- Administrative access through managed roles and named people, with open ports closed.
- Static sites, email and storage
- S3 and CloudFront for websites, SES for application email, and S3 for files and archives.
- Monitoring and cost
- Alerts on the things that matter, and regular reviews of what the account is spending.
How we take over an AWS environment
Inventory
Every server, database, bucket, user and open port, with what each is for and what it costs.
Safety first
Snapshots before anything changes, and a tested restore of the main database.
Close the obvious gaps
Unused access removed, management ports closed to the internet, secrets moved out of files.
Make change safe
A staging environment and a repeatable release, so changes are rehearsed before production.
Keep it current
Regular patching, version upgrades planned ahead of end-of-support dates, and a monthly look at cost.
A good fit when
- The application runs on AWS and nobody is responsible for the servers.
- Windows Server or SQL Server on your instances is near or past end of support.
- Releases go straight to production because there is nowhere to test them.
- The AWS bill has grown and nobody can say why.
Probably not for you if
- You need a managed service provider for desktops, email and office IT; we look after business applications and the hosting they run on.
Questions we are asked
Should we move from EC2 to managed services such as RDS?
Sometimes. A managed database removes patching and backup work, but costs more for some licences and limits some SQL Server features. We compare the two for your system before recommending either.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.