An adviser discusses access rights to shared cloud files with a client.
Back to the service overview Cloud & SaaS

Cloud operating models in detail.
Plan operations and transitions.

Compare SaaS, public cloud, private cloud, hybrid and privately operated systems. Clarify migration, access, ongoing costs and data return early.

The operational decision

What should become easier, and what must keep working?

Shared files, email or a custom application can justify a transition. DAXS records the workflow and assesses existing systems, reliance on internet connectivity and costs over the intended period of use.

Five models with different responsibilities.
ModelControl and operationsDependencies and recovery options
Privately operated systemsHardware and applications under your organisational control; plan maintenance, replacement and support.Location, power and hardware; plan backup and recovery yourself.
SaaSUse a ready-made application. The provider supplies agreed functions; users, permissions and content still need to be managed.Internet connectivity and product limitations; check export, retention, contracts and switching options.
Public cloudConfigure resources and platform services. Effort depends on the layer supplied by the provider.Usage charges, provider and service dependencies; check data location and fallback options specifically.
Private cloudUse a private or dedicated platform; define access, resources and responsibilities.Operator, location and agreed operations; assess backup and restoration separately.
HybridConnect local tasks to external services; coordinate identities and data paths across boundaries.Connections and both environments; assess outages and exit options for each part.
Four practical tasks

The application guides the choice.

Move email and collaboration

Mailboxes, calendars, files and users need to keep working in Microsoft 365 or Google Workspace. DAXS checks the existing setup, sharing and data transfer and plans the transition. Acceptance verifies important workflows.

Share files across locations

Multiple copies and unclear sharing permissions create extra questions. We organise storage locations, permissions and external sharing. Sign-in and access are tested on the devices actually required.

Host a custom application

An application needs to be accessible in a data centre or on a cloud platform. Resources, databases, access and ongoing support are planned. Costs, monitoring and recovery options are part of the decision.

Connect local business software

Data originates locally and is needed in an external service. DAXS checks interfaces, data quality and error handling. Transfers must be able to resume with clear controls after an interruption.

Tasks remain shared

Who supplies the service, and who manages its use?

IaaS, PaaS and SaaS with operational tasks for the business and provider.
Overview of operational responsibilities. The specific service and agreed operational scope determine the details.
  1. 01Provider

    Supplies the contractually agreed application, platform or infrastructure. Included backups, availability and support are read and assessed specifically.

  2. 02Your business

    Defines business requirements, users, sharing, content and permitted data use. Decides on contracts, budgets and organisational responsibility.

  3. 03DAXS

    Can handle migration, configuration, integration, permissions, monitoring and documentation. The agreed scope determines which tasks are actually supported.

Further background: Microsoft on shared responsibility for cloud services. The diagram shows a simplified allocation of operational responsibilities.

A transition needs acceptance testing

Test daily work as part of setting up users.

Identities, multifactor authentication, devices and sharing are configured. Data transfer, user introduction and an agreed cutover time are included.

Test business functions

Can an order be processed, a file opened and a meeting started? The test checks the required workflows with the responsible people. Identified gaps are addressed before acceptance.

Plan for internet outages

A SaaS service may be unusable without a suitable connection. Fallback connectivity, local options and contingency procedures are checked in advance. A second connection does not replace testing the entire workflow.

Exit options belong in the selection process

How can your business get its data out again?

Switching providers becomes difficult when formats, interfaces or contracts are checked only at the point of exit. DAXS considers export and possible reverse migration from the start.

  1. 01Data and formats

    Which content, attachments, permissions and metadata can be exported? A sample is checked for readability and further use.

  2. 02Contracts and dependencies

    Record contract terms, additional functions, identities and connected applications. Consider operating, transfer and switching costs separately.

  3. 03Backup and transition

    Plan independent recovery paths as required. Prepare the target environment, transfer and business tests before ending the existing service.

Azure, Google Cloud and other platforms are assessed for each scenario. Cloudflare may be useful for DNS, website connectivity or access routes; it does not replace the operating-model decision.
A possible project

Select a service by the tasks involved in operating it.

A custom application, shared files and email do not automatically need the same cloud model. DAXS compares which layer a provider supplies for the specific workflow and which tasks still need to be organised. Local systems and self-managed operations remain possible tools too.

Read the service scope

Maintenance and configuration differ between infrastructure, platform and application services. Data, users and sharing still require active management. What is actually included follows from the specific service and agreed scope, rather than the model name alone.

Make the decision verifiable

Costs are assessed for the intended operation: resources, licences, support, transfer and exit. A pilot checks sign-in, data access and required functions. We assess export options and a suitable recovery path before existing services are ended.

View planning and acceptance points
  • Record workflows, data and required availability.
  • Divide operational tasks between the business, provider and IT.
  • Check access, identities and connections.
  • Compare ongoing costs and organisational dependencies.
  • Test export and transition with a suitable example.
  • Acceptance: check workflows, support and a documented recovery path.

Example review framework. Scope and suitable evidence are agreed for your environment.

BEFORE YOU DECIDE

Questions about cloud and SaaS.

Is cloud always cheaper?
No. Licences, resources, storage, data traffic, additional functions, support and a later exit all belong in the comparison with your own systems.
Is cloud automatically secure?
Providers can offer strong protection functions. Identities, permissions, device protection, configuration and recovery also need to be set up and maintained appropriately.
Can local and cloud services work together?
Yes. Data paths, identities and application dependencies are coordinated. A hybrid model needs to provide a concrete benefit and remain maintainable.
What happens if the internet connection fails?
That depends on the dependencies. Local services can keep working if they do not require external services. For SaaS-only use, fallback connections or contingency procedures are assessed.
Can existing devices and applications remain usable?
Often, yes. We check suitability, support, access routes and dependencies. Introducing cloud services does not automatically require a complete replacement.
How is a change of provider prepared?
Data export, interfaces, identities, contract terms and exit options are considered in advance. The actual effort is assessed for the service concerned.
THE NEXT PRACTICAL STEP

Review a service for benefits, costs and exit options.

Tell us which workflow should become easier. We will compare suitable models and an initial assessment or migration step.

Simply explained

This page explains cloud models, the tasks of providers and businesses, implementation and a later transition in detail.