3-What are cloud migration types and models :

Enterprises today have more than one cloud model from which to choose:

 Public : The public cloud lets many users access compute resources through the internet or
dedicated connections.
 Private : A private cloud keeps data within the data center and uses a proprietary
architecture.
 Hybrid : The hybrid cloud model mixes public and private cloud models and transfers data
between the two.
 Multi-cloud : In a multi-cloud scenario, a business uses IaaS options from more than one
public cloud provider.

Beyond this initial choice of cloud model, there are three major cloud categories that should be
considered for cloud deployments:

 Infrastructure as a service. IaaS is the classic "utility computing" model where computing,
storage and services such as firewalls and load balancers are made available to users who
select and compose the cloud infrastructure in a way that is best suited for the workload
being deployed to the cloud.
 Platform as a service. Platforms are cloud offerings designed to provide specific or highly
integrated capabilities that alleviate the need for users to deploy and maintain such
capabilities themselves. PaaS examples include a cloud-based software development
platform or a container deployment/management platform.
 Software as a service. In the SaaS category, the cloud service provides users with access to
one or more specific workloads, such as productivity applications like Microsoft's Office 365
or Concur for employee expense reporting and reimbursement. Using SaaS eliminates the
need for a business to deploy and maintain that application -- instead leaving the
development, operation and maintenance of the application to the provider.

It's important to note that all three cloud categories can be used concurrently in any combination
that suits the needs of the particular business.

4-How does the cloud migration process work:

1. Understand the purpose. This is the "why" of any cloud migration. Every cloud migration
should start by defining tangible business purposes for the migration and set clear
expectations from the migration project. If the business cannot identify at least one tangible
or measurable reason for a migration, it's often best to pause the project early on.
2. Determine the target application(s). This is the "what" of the cloud migration project, where
business, technical and compliance leaders assess the local environment and identify
potential candidates for a cloud migration. Not every workload is suited to the cloud because
of performance, security, compliance or other issues, so deciding what workload(s) should be
included in a migration is a vital step forward. In addition, a migration is not an all-or-nothing
process. It's often advisable to migrate workloads as individual projects rather than epic all-
encompassing transformations. Migrations must include all dependencies, such as related
databases, in the migration project.
3. Choose the cloud target. This is the "where" of a cloud migration project. Once an application
is selected for a cloud migration, the business can select the cloud deployment model -- such
as public, private, hybrid or multi-cloud, as well as IaaS, PaaS or SaaS -- that is best suited as
the destination. For example, a simple migration using a SaaS offering to replace an aging
local workload might involve a leading SaaS provider, while an advanced business
transformation strategy might involve creating a private cloud, establishing a hybrid cloud
and then making the migration.
4. Select a proven cloud partner. It's important to consider cloud targets carefully to ensure that
the provider has a proven track record and will be in business for the foreseeable future. This
might seem like an excessive precaution, but provenance is everything in cloud computing.
The most disruptive event for a business is finding that a vital provider is closing its doors,
forcing businesses to scramble to find alternative providers -- often with undesirable
outcomes.
5. Evaluate migration costs and needs. A cloud costs money, and any migration project must
consider the costs of migration. This typically includes per-month fees for a SaaS, per-user
fees for a PaaS and the various costs of IaaS resources and services. Since cloud costs are
recurring, businesses will need to budget appropriate funds for migration and ongoing
support. Similarly, understand the performance requirements and expectations from the
workload once the migration is complete, and be prepared to establish metrics and KPIs for
ongoing workload performance monitoring and reporting.
6. Choose the appropriate architecture. While PaaS and SaaS architectures are largely set and
their costs are relatively straightforward to determine, composing an architecture for a
workload within an IaaS cloud environment can be challenging -- especially for highly scalable
architectures. It requires the efforts of a skilled cloud architect with expertise in the chosen
cloud target to compose an environment with the reliability, security, monitoring and
performance to meet the workload's needs. Cost data from IaaS architectural designs should
loop back to refine the cost analysis and budgeting for the workload.
7. Create the migration plan. This is both the "when" and "how" of the cloud migration,
enabling a business to outline its approach and timeline for the actual migration. The plan
should include provisions for detailed data migration; testing and validating dependencies
first, such as the required databases; moving the intended target workload; and then
performing all final testing and validation. Only then should there be a clear cutover process
to turn the local workload off and turn the newly migrated cloud workload on. Finally, there
should be consideration of rollback processes for failed or problematic migrations. Any
migration testing should include detailed attention to access and security.
8. Perform the migration. With all the pieces and plans in place, the business can migrate data
and workloads in accordance with its migration plan. This is where all of the movement and
detailed testing takes place. Business and technology leaders -- and often workload owners --
should see initial performance reporting to ensure adequate performance and security under
full load. Cautious migration plans might run the cloud and local workloads concurrently for a
short time, syncing data and opening the cloud workload to systematically more users until
the cloud deployment is fully validated and cutover.
9. Follow monitoring and reporting. Cloud workloads are typically instrumented with
performance monitoring services to track workload availability, access, health and
performance as it runs in the cloud. Stakeholders should verify that reporting is available and
KPIs meet expectations.
10. Follow-up and organizational changes. There might be some aftermath to a cloud migration.
At the technical level, the local resources -- such as servers and storage -- previously utilized
by the local workload might be freed for reuse or decommissioned to save power and cooling
costs for the business. At the business or organizational level, the movement of a workload
into the cloud might result in some staff reassignment. For example, moving a custom
workload to a SaaS offering could free developers to work on other projects.