Move your databases and applications to the cloud, one sensible step at a time.
We move on-premise databases such as Oracle and SQL Server, and the applications that depend on them, to AWS, Microsoft Azure or Google Cloud. Each workload gets the right strategy, from a straight rehost to a managed database, so you leave the data centre with less risk and fewer surprises.
Why migrate databases and applications now
Most estates have grown over years: Oracle and SQL Server databases, Windows and Linux servers, line of business applications and file shares, often on hardware near the end of its life. Software support dates add pressure. SQL Server 2016 left extended support in July 2026 and Windows Server 2016 follows in January 2027. Moving everything the same way wastes effort. Some workloads should simply be retired, some rehosted, and some moved to a managed database that removes patching and backup work for good.
Ageing software and hardware
Unsupported databases and operating systems carry security risk. A migration is the right moment to upgrade them.
Database administration effort
Managed database services take over patching, backups and high availability, so your team spends less time on routine work.
Licence choices
Moving from a commercial database to PostgreSQL is possible for many applications, and native tools now help convert schemas and code.
Dependencies you cannot see
Applications often depend on each other in ways that are not documented. Discovery tools reveal those links before anything moves.
What we do
We plan and run migrations of databases and applications using native cloud tooling.
Discovery and assessment
We inventory servers, databases and applications, and map dependencies using native discovery tools. You see what you have, how it is used and what it would need in the cloud.
7 Rs strategy per workload
We assign each workload a strategy: retire, retain, rehost, relocate, repurchase, replatform or refactor. The aim is to move fast where change adds no value and modernise where it does.
Server rehosting
We replicate servers continuously to the cloud and cut over in short windows. Applications keep running while data copies in the background.
Database migration
We move Oracle, SQL Server, MySQL and PostgreSQL databases with native replication tools that keep source and target in sync until cutover. Downtime is limited to the final switch.
Database modernisation
Where it makes sense, we convert Oracle or SQL Server databases to managed PostgreSQL services, using schema conversion tools and testing the application against the new engine.
Testing and cutover
We run functional, performance and data checks, then plan the cutover with rollback options. We stay close through hypercare.
How it works
- 1
Discover
We deploy discovery tools and collect inventory, utilisation and dependency data. Business owners confirm what each application is for.
2 to 4 weeks - 2
Plan waves
We choose a strategy for each workload and group them into migration waves by dependency and risk. You get a wave plan and target designs.
2 to 3 weeks - 3
Prepare the landing zone
We set up accounts or subscriptions, networking, identity, security and backup in the target cloud.
2 to 4 weeks - 4
Migrate in waves
We migrate and test each wave, starting with low risk workloads to prove the process. Lessons from each wave improve the next.
2 to 6 weeks per wave - 5
Optimise and close
We right-size resources, decommission old servers and hand over to your team or our managed service.
2 to 4 weeks
Native migration tools by cloud
The services we use for discovery, migration and target databases on each cloud.
| Need | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Discovery and planning | AWS Transform | Azure Migrate | Migration Center |
| Server rehost | AWS Transform MGN | Azure Migrate | Migrate to Virtual Machines |
| Database replication | AWS Database Migration Service | Azure Database Migration Service | Database Migration Service |
| Schema and code conversion | DMS Schema Conversion | SQL Server Migration Assistant | Database Migration Service conversion workspaces |
| Managed SQL Server | Amazon RDS for SQL Server | Azure SQL Managed Instance | Cloud SQL for SQL Server |
| Managed PostgreSQL | Amazon Aurora PostgreSQL-Compatible Edition | Azure Database for PostgreSQL flexible server | AlloyDB for PostgreSQL |
| Oracle Database inside the cloud | Oracle Database@AWS | Oracle Database@Azure | Oracle Database@Google Cloud |
Migrating the systems around SAP
SAP rarely stands alone. Around it sit SQL Server and Oracle databases for reporting, custom portals, interface servers, file transfer servers and third party applications that read or write SAP data. When SAP moves to the cloud, whether self-managed or under RISE with SAP, these systems need to move with it or close to it, otherwise interfaces slow down and the data centre cannot close. We migrate them in the same plan, in the same region as SAP where possible, and reconnect them to the new SAP landscape.
- We map which non-SAP systems exchange data with SAP and move them in waves that match the SAP cutover.
- Interface and file transfer servers are placed near SAP to keep latency low.
- SAP databases themselves move with SAP tools such as Software Update Manager with Database Migration Option, not generic database tools.
- Where reporting databases duplicate SAP data, we look at whether SAP Business Data Cloud or Databricks can replace them.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
Deliverables
- Inventory and dependency map of servers, databases and applications
- 7 Rs strategy for every workload
- Wave plan with target designs and cutover runbooks
- Migrated and tested databases and applications
- Decommissioning plan for source systems
- Handover documentation and optimisation recommendations
Frequently asked
What are the 7 Rs?
They are seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor. Each workload gets the one that fits its value, risk and future. For large migrations, rehosting or replatforming first and modernising later is usually safer than refactoring during the move.
Can we move Oracle databases to the cloud without changing them?
Yes. You can run Oracle on cloud virtual machines, or use Oracle Database@AWS, Oracle Database@Azure or Oracle Database@Google Cloud, which run Oracle services inside the hyperscaler's data centres. All three are available in regions in India. Licensing needs to be checked for each option.
Can we move from Oracle or SQL Server to PostgreSQL?
Often, yes. Native tools on each cloud convert schemas and code to PostgreSQL and replicate the data. The application still needs testing, and some packaged software only supports specific databases, so we check vendor support first.
How much downtime should we expect?
With continuous replication, the source keeps running while data copies, and downtime is limited to the final cutover. The exact window depends on the application and we measure it in rehearsals.
What happens to our SQL Server 2016 databases?
SQL Server 2016 extended support ended in July 2026. Options include upgrading during the migration, moving to a managed service such as Azure SQL Managed Instance or Amazon RDS for SQL Server, or using Extended Security Updates while you plan.
Often paired with this
Plan your move with people who know SAP.
One working session with our cloud and SAP architects. You leave with the options, the risks and a first plan.
- Your landscape reviewed
- The right cloud and region
- A first roadmap
Sources
- AWS Prescriptive Guidance: the 7 Rs migration strategies
- Microsoft Lifecycle: SQL Server 2016
- Oracle: Multicloud regional availability
- Microsoft Learn: About Azure Migrate
- Google Cloud: Database Migration Service supported databases
- AWS: Application Migration Service is now AWS Transform MGN
- AWS: Migration Hub availability change and AWS Transform
- AWS: DMS Schema Conversion with generative AI
- Microsoft: Windows Server 2016 end of support
The Nollane Rule is our shorthand for looking after the details nobody sees in Database & Application Migration.
AWS, Microsoft Azure, Google Cloud and SAP are trademarks of their respective owners.