What are cloud services?
Cloud services provide computing capabilities such as applications, storage, servers, databases, networking, analytics, identity, and backup over a network from a shared or dedicated pool of provider-managed resources. Customers can provision or consume those capabilities without owning every layer of the underlying infrastructure.
The widely used NIST definition of cloud computing describes characteristics such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Those characteristics explain the operating model; they do not guarantee that every cloud product is flexible, inexpensive, secure, portable, or appropriate for your organization.
Cloud is a responsibility model, not a location
Moving a workload changes who operates each layer. A provider may maintain data centers, hardware, and parts of the platform. The customer still makes decisions about identities, access, data, configuration, devices, retention, integrations, recovery, and acceptable use to varying degrees. The exact boundary depends on the service and contract.
Cloud is already part of most businesses
Email, collaboration, payroll, accounting, CRM, file sharing, backup, phone systems, websites, and line-of-business applications may all be delivered as cloud services. A cloud strategy therefore is not only a decision about moving servers. It is a way to govern the portfolio of services, identities, data, vendors, costs, integrations, and recovery commitments the business already depends on.
Cloud should not become another isolated technology project. Its value depends on how well it supports the wider managed IT, cybersecurity, data, and AI operating model and the outcomes the organization is pursuing.
SaaS, PaaS, IaaS, public, private, and hybrid cloud
These terms describe different service and deployment models. Understanding them helps a buyer compare responsibility, customization, skill, and cost.
Software as a Service (SaaS)
You use a provider’s application, commonly through a browser or managed client. Microsoft 365, many CRM and accounting platforms, and hosted ticketing systems are examples. The provider operates the application and underlying platform, but the customer typically remains responsible for users, access, configurations, data, integrations, endpoint security, and many retention and recovery choices.
Platform as a Service (PaaS)
The provider operates more of the runtime, middleware, database, or development platform while the customer deploys applications and manages its data and configurations. PaaS can reduce infrastructure administration, but it may introduce service-specific design, scaling, logging, security, and portability decisions.
Infrastructure as a Service (IaaS)
The provider supplies virtualized computing, storage, and networking. The customer usually manages operating systems, applications, identities, configurations, patches, data, monitoring, and recovery above that layer. Moving an unchanged server into IaaS may relocate technical debt without modernizing the workload.
Public, private, and hybrid deployment
Microsoft 365, Azure, and cloud backup are different
Microsoft 365 is a family of SaaS services. Azure provides IaaS, PaaS, identity, data, integration, security, and other capabilities. A cloud backup service stores protected copies and may support recovery, but it is not the same thing as hosting an application or making that application highly available. Clarify which service and responsibility a proposal means when it says “the cloud.”
When does cloud make sense for a business?
Cloud decisions should begin with business and workload requirements, not a universal migration target. NIST’s cloud synopsis and recommendations describes both opportunities and risks and encourages organizations to evaluate requirements deliberately.
Cloud may be a strong fit when
- A supported SaaS product can replace infrastructure and application maintenance the organization does not want to own.
- Users need secure access across locations and devices, with centralized identity and collaboration.
- Demand changes enough that measured, elastic capacity provides operational value.
- A new application benefits from managed database, integration, analytics, or development services.
- The organization needs capabilities, geographic reach, or service speed that would be difficult to build internally.
- Existing hardware or software is approaching end of support and the business is willing to redesign rather than only relocate it.
On-premises or hybrid may remain reasonable when
- A production system depends on local equipment, specialized interfaces, or low-latency control.
- Connectivity is constrained and the workload must operate through an internet outage.
- A supported application is not designed or licensed for the proposed cloud environment.
- Data, customer contracts, export restrictions, or sector requirements create conditions the proposed service cannot meet.
- A stable workload has a well-understood operating cost and migration would not produce enough benefit to justify disruption.
- Skills, support, security, recovery, and governance are not ready for the target platform.
Cloud is not automatically cheaper
Cloud changes the cost model. It can reduce capital purchases and provide flexible services, while introducing ongoing licenses, consumption, data transfer, premium security, backup, support, and management costs. Compare total operating requirements and business value over a realistic period.
How to decide where a workload belongs
Evaluate workloads individually, then account for dependencies between them. An email platform, production database, file repository, domain controller, backup system, analytics environment, and legacy application may have different answers.
Business requirements
- Who uses the service, where, on which devices, and during what hours?
- What business process depends on it, and what happens when it is unavailable or slow?
- Is the workload differentiating, or could a standard SaaS product meet the need?
- How quickly must the business change capacity, features, locations, or integrations?
Data and obligation requirements
- What data is stored, processed, transmitted, logged, backed up, and exported?
- Which privacy, contractual, customer, insurance, retention, deletion, or location requirements apply?
- Who owns the data, encryption keys, tenant, domains, configurations, and administrative accounts?
- Can the organization export usable data and records if the service changes or the relationship ends?
Technical requirements
- Application and database compatibility, vendor support, licensing, latency, bandwidth, and integration dependencies.
- Identity, device, network, segmentation, encryption, logging, monitoring, patching, and vulnerability needs.
- Availability, backup, recovery time, recovery point, failover, rollback, and testing expectations.
- Performance patterns, growth, data transfer, automation, and administrative skill.
Economic and operating requirements
- Migration, refactoring, parallel operation, licensing, consumption, support, training, security, backup, and exit costs.
- Who monitors the service, investigates alerts, manages access, optimizes cost, tests recovery, and handles vendor escalation?
- How provider outages, product changes, price changes, deprecations, and contract renewal will be managed.
Document the decision and assumptions. A workload can change categories as the application, provider, business, or risk changes.
Cloud security and the shared responsibility model
Cloud providers secure portions of the service; customers secure their use of it. Microsoft’s shared responsibility guidance shows how the boundary changes across on-premises, IaaS, PaaS, and SaaS. Customers retain responsibility for their data, accounts, identities, and access, while responsibility for applications, operating systems, networks, and physical infrastructure varies.
The business cybersecurity pillar covers the wider governance, asset, identity, device, detection, response, and supplier practices that should surround cloud services.
Cloud availability, backup, and disaster recovery are not the same
A provider service-level agreement describes specific availability commitments and remedies under defined conditions. It is not your business recovery plan. An application can be online while data is deleted, encrypted, corrupted, misconfigured, or inaccessible to your users.
Define business recovery objectives
These are business decisions informed by technology and cost. Not every system needs the same objective.
Clarify native retention and backup
Version history, recycle bins, replicas, snapshots, retention policies, legal holds, and third-party backups solve different problems. Ask what events each protects against, who can alter or delete copies, where copies reside, how long they remain, and how recovery is performed.
Test the recovery path
Monitor backup jobs, but also restore representative files, records, configurations, and systems. For critical workloads, exercise dependencies, identity, communications, vendor contacts, failover, and return to normal operation. Record results, gaps, owners, and corrective actions.
Cloud resilience should coordinate with your managed IT responsibilities, described in the managed IT services buyer’s guide.
How to plan a cloud migration
A migration is a business change with technical work inside it. The Azure migration-planning guidance emphasizes discovery, assessment, sequencing, stakeholder coordination, rollback, and validation. Those disciplines apply whether the destination is Azure, Microsoft 365, another SaaS platform, or a hybrid environment.
- Discover. Inventory applications, servers, data, users, identities, integrations, network flows, vendors, certificates, schedules, support history, and hidden manual steps.
- Assess. Confirm business criticality, ownership, compatibility, support, security, obligations, recovery needs, performance, cost, and dependencies.
- Choose a disposition. Retain, retire, replace with SaaS, rehost, replatform, refactor, or redesign. Do not migrate a system only because it appears on the inventory.
- Design the target. Define tenant and subscription structure, identity, network, data, monitoring, management, security, backup, recovery, cost controls, and operating roles.
- Pilot. Test representative users, data, integrations, devices, performance, support, and recovery with controlled scope.
- Plan cutover and rollback. Set change windows, communications, data synchronization, validation, decision authority, fallback conditions, and vendor coverage.
- Migrate and validate. Confirm data, permissions, integrations, performance, security, logging, backup, licensing, and user workflows, not only that the application opens.
- Stabilize and decommission. Monitor, resolve issues, train support teams, update documentation, remove old access, and retire systems only after retention and recovery obligations are met.
Plan for people and process
A file migration may change search, sharing, naming, approvals, remote access, document ownership, and how employees collaborate. Assign business champions, communicate what changes and what does not, train users in the real workflow, and provide a clear support path.
If the migration is intended to enable Microsoft 365 Copilot, review permissions and information governance first. Our Copilot deployment guidance explains why licenses alone are not a rollout plan.
Cloud cost and licensing governance
Cloud waste is rarely one dramatic purchase. It grows through unused licenses, oversized resources, forgotten environments, premium features enabled without ownership, uncontrolled storage and logs, data transfer, duplicated tools, and renewals no one reevaluates.
Make ownership visible
- Assign a business and technical owner to material services, subscriptions, resources, integrations, and licenses.
- Use account, subscription, resource-group, naming, labeling, or tagging structures that connect spend to a purpose.
- Set budgets and alerts, but also define who investigates and what action is permitted.
- Review unused users, dormant resources, old backups, test systems, premium tiers, and reservations on a schedule.
- Include support, security, backup, networking, data transfer, management, and exit costs, rather than considering only compute or license price.
Optimize continuously
Rightsizing once is not cost governance. Demand, pricing, features, and business priorities change. The FinOps principles emphasize collaboration, business-value decisions, timely data, accountability for usage, and continuous use of the variable cost model. A small business can apply those principles without creating a formal FinOps department.
Read the licensing boundaries
Confirm prerequisites, minimum commitments, add-ons, storage, API use, connectors, security capabilities, backup, support, and price-change terms. A feature shown in product documentation may not be included in the license quoted. Software and cloud fees are often separate from migration and managed-service labor.
For broader technology budgeting, review the managed IT services guide to understand which support, security, and planning responsibilities may sit outside the cloud-project quote.
What can managed cloud support include?
Managed cloud support can cover some combination of tenant administration, identity, licensing coordination, configuration, monitoring, patching for customer-managed layers, backup, recovery testing, security operations, vendor escalation, cost review, documentation, user support, and roadmap planning. Migration and major changes may be separate projects.
The provider, platform vendor, software vendor, customer leadership, internal IT team, security specialists, and application owners may all retain responsibilities. Put the division in writing. “We manage your cloud” is not an adequate scope statement.
Questions to ask a cloud or managed service provider
- Which tenants, subscriptions, applications, identities, devices, networks, data, and locations are in scope?
- Which work is recurring service, project work, vendor responsibility, customer responsibility, or excluded?
- Who owns the tenant, domains, licenses, subscriptions, configurations, encryption keys, backups, and administrative accounts?
- How does the provider secure, approve, log, review, and remove its privileged access?
- What is monitored, during what hours, by whom, and what response authority is included?
- How are backup scope, RTO, RPO, restore tests, incident roles, and recovery charges documented?
- How are Microsoft or other vendor recommendations evaluated before changing production?
- What cost, license, security, service, and lifecycle reporting will leadership receive?
- Which subcontractors and tools can access the environment or data?
- What documentation, exports, and transition assistance are provided at termination?
Warning signs
Watch for these
- A universal recommendation to move everything or a guarantee that cloud will save money.
- Security described only through provider certifications or product names.
- No application-dependency discovery, rollback plan, recovery test, or post-cutover operating owner.
- A proposal that does not separate licenses, consumption, support, project work, and ongoing management.
- The provider controls the tenant or domain in a way that prevents the customer from maintaining ownership and independent access.
Monreal IT approaches cloud work as part of a connected technology roadmap, with discovery, design, implementation, support, and ongoing improvement prioritized in practical stages rather than as a one-time migration event. Review the Monreal IT managed services overview and case study library for broader context. Any cloud migration, Azure architecture, Microsoft 365 change, or ongoing management commitment should be confirmed in the specific proposal and statement of work.