Get more from the cloud with Oblytech’s expert consulting and migration services. We guide you through every step of your cloud journey, from strategy and planning to smooth execution and ongoing optimization.
We assess your business needs and develop a tailored cloud strategy to meet your goals, outlining a roadmap for successful implementation.
We evaluate your existing infrastructure, applications, and processes to determine their suitability for cloud migration and identify potential challenges.
We help you choose the right cloud platform (AWS, Azure, Google Cloud, or hybrid) that fits your requirements and budget.
We create a detailed migration plan to help make the transition of your data, applications, and workloads to the cloud smooth and efficient.
We design a scalable and secure cloud architecture that is built to balance performance and cost efficiency.
We monitor and fine-tune your cloud environment to help improve resource utilization and reduce cost.
We implement security measures to protect your data and applications in the cloud, and we take industry regulations into account.
Cloud migration projects are often framed as a question of provider: which platform, which region, which contract. The more consequential question comes first. Each application in the estate has to earn its place in the destination, and some should not move at all. A system that is scheduled for replacement next year may be cheaper to retire than to relocate. A system that depends on a database with a license tied to the current hardware may need a separate decision before it can change. Without that sorting step, a migration tends to copy the existing costs and problems into a new environment and then bill them monthly.
| Approach for an application | What it means in practice | Typical reason to choose it |
|---|---|---|
| Rehost | Move the workload with little change to how it runs | A deadline that cannot move, or a system that is stable and rarely changed |
| Replatform | Keep the application logic but use a managed database or hosting service | A clear operational gain without a rewrite |
| Refactor | Redesign parts of the application to take advantage of the platform | A system with growth, scaling or release problems that justify the cost |
| Retain | Leave the application where it is for now, with a stated review date | A dependency that cannot change yet, or a regulatory constraint that needs separate work |
| Retire | Remove the application and move its useful data or function elsewhere | Low use, duplicated function or a planned replacement |
The labels above are general practice rather than a method owned by any one provider. What matters is that each application is assigned one of them, with a reason and an owner, before the migration schedule is fixed.
A readiness review is the step that turns a general wish to move into a list of decisions. It examines the applications and their dependencies, the data they hold and where that data may legally and practically sit, the network links they rely on, the identity and access model, and the operational processes that will change after the move. Many migrations fail on dependencies that were not recorded: a reporting job that reads from a file share, a supplier integration that expects a fixed address, or a backup process that nobody tested. A review that maps those links before the first workload moves is the cheapest insurance available.
The main public cloud platforms offer overlapping services, and a provider choice is usually made on the basis of existing skills, contracts, data location requirements and the software the business already uses. A hybrid arrangement, in which some workloads stay on premises for a period, is also common when a single application cannot move quickly. The choice should follow the dependency map and the skills available to run the environment. Choosing a platform first and then fitting the applications to it is the most common reason migrations need rework.
Cost needs the same discipline. Moving a server unchanged to a rented machine often costs more than the original, because the business pays for capacity that was never used on site. The cost comparison should use the actual usage pattern of each application, and it should include the people time needed to run the new environment, not only the monthly bill.
Migration waves are usually grouped by dependency rather than by department. A group of applications that talk to each other moves together, with a tested fallback for each one. Pilot waves should include a low-risk system so that the team learns the runbook before a critical service moves. Cut-over steps need a defined rollback point, and the team should agree in advance what would trigger a return to the original environment. Security and compliance controls should be built into the target environment before data arrives, not added once the move is complete.
A migration also changes how the estate is run. The team that restarted a server by hand in the old data center will need new routines for alerts, scaling and cost reviews. Those routines should be written and assigned during the project, because they are the first thing to lapse once the project team leaves.
| Question | A useful answer covers | A vague answer covers |
|---|---|---|
| How do you decide which applications should not move? | The retain and retire criteria, and who signs them off | A general promise to optimize the estate |
| How will you find dependencies we have not documented? | Network and job-level discovery, checked with application owners | Reliance on our own documentation |
| What is the rollback plan for each wave? | The trigger, the time window and the tested steps | A statement that rollback is available |
| Who runs the environment afterwards? | A named operating model and handover | Support will be available |
Timing, scope and price for a migration depend on several inputs. The main ones are the number of applications, the complexity of their dependencies, the data volumes and locations, the regulatory constraints on that data and the number of cut-over windows the business can accept. A quote issued before those inputs are known should be treated as an indication only.
Rarely. A single large cut-over concentrates risk into one window. Grouped waves let the team fix problems on a smaller scale and carry the lessons into later waves.
No. A hybrid estate is a legitimate end state for applications that cannot move yet. The point is to record why each one stays and when it will be reviewed again.
Compare the actual usage of each application with the cost of running it in the destination, and include the staff time needed to operate it. Comparing a rented machine with an old purchase price is not a valid test.
Backups should be defined for the target environment before the first cut-over, and a restore should be tested on real data. A backup that has never been restored is a hope, not a control.
A reasonable first step is to list the applications, the people who own them and the dates when each contract or license changes. Bring that list to a first discussion through the contact page, and describe any constraint on where data may be held. The answer should show which applications are candidates for early waves and which need more analysis.
The cloud services overview covers Azure, AWS and Google Cloud, and the IT strategy and planning page covers IT strategy and planning more broadly. Teams that intend to automate the environment once it is running may want the DevOps and automation page. Organizations that also need support for the new environment can look at the remote IT support page.
The first weeks after a cut-over are when migration faults show up, because real users and scheduled jobs run against the new environment for the first time. Use that period to check four things against the baseline recorded before the move: performance, restores, cost and ownership of alerts.
Performance comes first. Compare response times and batch completion times with the figures from the source environment, not with a sizing guide. A workload that runs slower after the move usually has a different network path, storage class or connection pool, and those differences are easier to find while the old environment is still available for comparison.
Backups need a restore test in the new location. A backup job that reports success does not show that the data can be brought back. Restore one representative database and one file set to a separate target, then record how long the restore took and whether the application started afterwards.
Cost needs the same attention. Data transfer, storage tiers and idle capacity are often billed on separate lines from the main compute charge, so compare the first full billing period with the estimate and explain each difference in writing. Any line that cannot be explained goes back to the owner of that workload.
Alerts and support routes are easy to overlook. If the old monitoring still sends mail to a former administrator, the new environment has no one watching it. Confirm that each alert reaches a team that will act on it. Ongoing support for migrated systems is the part a managed service covers, and the managed IT services overview and the application management page describe how that is run. Governance of cloud resources after the move is covered in cloud provisioning and governance.
Assign these checks before cut-over, with an owner and a date for each, so the first weeks are spent finding problems rather than deciding who looks for them. Keep the source environment available until the restore test and the first billing review are complete.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.