Five Questions to Ask About Data, Access, and Control in Vendor Clouds

TL;DR

• A software-vendor cloud can simplify hosting for one application, but it may change how you access databases, maintain customisations, run integrations and control upgrades.

• Before moving Primavera P6, EcoSys or another project controls application, document the complete environment and confirm what will continue to work.

• Ask where your data will reside, how it can be exported and who provides support when an issue crosses application and infrastructure boundaries.

• Compare the full responsibility of the vendor cloud with managed application hosting, not only the subscription price.

• Record the exit process before signing, including data formats, migration support, notice periods and likely costs.

Moving an established project controls application to its software vendor’s cloud can appear to be the simplest path away from ageing infrastructure. The developer hosts the software and maintains the standard environment. For some organisations, that is the right choice.

But a project controls environment is rarely just one standard application. Primavera P6, EcoSys, Autodesk products and other specialised systems may depend on particular databases, configurations, integrations, reports and access controls. A hosting change can affect all of them.

Before moving project controls software to a vendor cloud, determine what your organisation will gain, what it may give up and what work will remain with internal IT. Microsoft’s cloud shared-responsibility guidance shows that customers retain responsibility for data, identities and configurations even as other responsibilities shift by service model.

These five questions expose the practical differences before they become migration problems.

1. Will You Retain the Database Access You Need?

Many organisations use direct database access to support reporting, integrations, audits and established project controls processes. Moving to a software-vendor cloud may change that access because the vendor controls the underlying environment.

Before agreeing to the move, document every process that depends on the application database. This may include scheduled extracts, business intelligence reports, data validation, integrations with ERP or document-management systems and troubleshooting procedures.

Ask the vendor:

• Will we retain direct database access?

• Which tables, schemas, APIs or export methods will be available?

• How frequently can data be extracted?

• Are there additional fees or limits?

• Will our existing reporting pipelines continue to work?

• How will historical data be migrated and validated?

Do not assume that an API or standard export provides the same access as your current database. Test whether the proposed method supports the data, frequency and performance your organisation requires.

If it does not, include any new extraction processes, reporting changes or additional infrastructure in the migration plan and business case.

2. How Much Customisation Will You Lose?

Most on-premises systems evolve over years. Organisations build scripts, workflows, dashboards and extensions that fit how the business operates. That flexibility is one of the strengths of managing an application environment directly.

Vendor clouds work differently. They generally standardise the environment to simplify support and upgrades. That can improve consistency, but it may also limit:

• Bespoke integrations that are not supported by the vendor

• Custom fields, layouts or reports

• Local scripts and scheduled tasks

• Application configurations tuned for performance or specific business rules

• Control over when upgrades occur

Before migrating, audit every script, workflow, report, custom field and configuration. Categorise each as business-critical, useful or replaceable.

For anything business-critical, ask whether it will continue to work, require rebuilding or be unsupported in the vendor cloud. Confirm who will complete and test any necessary changes.

Migration can be an opportunity to remove customisations that no longer provide value. The important point is to make those decisions deliberately rather than discovering the limitations after the new environment is live.

3. Will Your Integrations Still Work?

Most project organisations do not operate within a single software ecosystem. Applications such as Primavera P6, Sequence Enterprise (EcoSys) and Autodesk products exchange information with cost, estimating, risk, design, reporting, ERP and document-management systems.

A vendor cloud may use different APIs, security controls, database access or supported versions from your current environment. Integration traffic may also cross new networks or regions. Any of these changes can affect reliability and performance.

Before migrating, create an integration map that identifies:

• The applications and databases connected

• The direction and frequency of each data exchange

• The interfaces, ports, APIs and service accounts used

• The owner of each integration

• The business process affected if it fails

Ask the vendor to confirm which integrations are supported, which will require modification and which cannot operate in the proposed environment. Test critical connections with realistic data and transaction volumes before cutover.

The hosting decision should support the complete project technology environment—not isolate one application while shifting integration problems back to internal teams.

4. How Much Operational Visibility and Governance Will You Have?

When a software vendor controls both the application and hosting environment, customers may have less access to infrastructure monitoring, administrative settings and root-cause information. The level of visibility varies, so it should be established before migration rather than assumed.

Ask what your team will be able to see about:

• Application availability and performance

• User activity and access

• Backups and recovery

• Security events

• Incident status and root cause

• Service usage and cost

Confirm who investigates a slowdown when the cause could involve the application, database, infrastructure, network or user location.

Data location also matters. Establish where project data will be stored, processed, replicated and backed up. Ask whether you can select or restrict regions and how the vendor demonstrates compliance with contractual, regulatory and client-specific requirements.

Review the service-level agreement for:

• Uptime commitments

• Support hours and response times

• Escalation procedures

• Backup frequency and retention

• Recovery objectives

• Security incident notification

• Root-cause reporting

Convenience should not leave your organisation unable to understand the performance, security or location of a project-critical system.

Related reading: 4 Ways to Prevent Cloud Application Performance Issues

5. What’s Your Exit Strategy?

The best time to understand how to leave a vendor cloud is before entering it. Once a renewal or migration deadline approaches, your organisation may have too little time to extract data, rebuild integrations and establish a replacement environment.

Ask the vendor to document:

• Available data-export formats

• Whether exports include historical, configuration and audit data

• How long a complete export takes

• Fees for extraction or migration assistance

• Contractual notice periods and renewal terms

• How long data remains available after termination

• Support for moving to another hosted or on-premises environment

Estimate the work required to restore identity controls, reports, integrations and configurations elsewhere. NIST’s Cloud Computing Standards Roadmap identifies interoperability and portability standards as important to cost-effective migration and avoiding premature technological obsolescence.

An exit plan does not assume the relationship will fail. It protects your organisation’s ability to change applications, hosting models or providers as project and business requirements evolve.

How Does Independent Managed Hosting Compare?

A software-vendor cloud generally provides a standard environment for that vendor’s application. Independent managed application hosting offers another model: your organisation retains its selected applications while a specialised provider manages the infrastructure and supporting environment.

This can be valuable when project teams:

• Use applications from several software vendors

• Depend on established configurations and integrations

• Need control over application versions and upgrade timing

• Require database access for reporting or connected systems

• Operate across regions with different performance or data-residency requirements

• Need support across application, database and infrastructure boundaries

A managed hosting provider can coordinate deployment, database migration, security, access, monitoring, backups, upgrades, application administration and support within one managed environment.

Neither model is universally right. A software-vendor cloud may suit a standard deployment with limited customisation or integration requirements. Managed hosting may be a better fit when application choice, operational control and coordinated support matter.

Related reading: Choosing a Project Controls Cloud? Here’s the Real Question to Ask.

Keep Control of the Decision

LoadSpring Managed Hosting provides a secure, fully managed environment for more than 200 project applications. LoadSpring manages the infrastructure, applications, security, access, monitoring, administration, updates, backups and support as part of the environment.

With 25 years of experience supporting project-intensive organisations, a 99.9% uptime guarantee and global live support available 24/7/365, LoadSpring gives customers one provider accountable for keeping their project application environment running.

Before committing to a software-vendor cloud, compare it with an independent managed hosting model using the five questions above. The goal is not to avoid every vendor cloud. It is to choose an environment that protects the access, flexibility and support your organisation requires.

Talk to a LoadSpring expert about your current application environment and hosting options.

FAQ

What Is a Software-Vendor Cloud?

A software-vendor cloud is an environment in which the company that develops an application also hosts and manages it. The vendor normally controls the infrastructure, supported configurations, upgrade schedule and available administrative access.

What Should Be Checked Before Moving Project Controls Software to a Vendor Cloud?

Check database access, reporting requirements, integrations, customisations, supported versions, upgrade control, security, data residency, service levels and the process for exporting data or leaving the service.

Does Moving to a Vendor Cloud Eliminate Internal IT Work?

Not necessarily. The vendor may manage its application and infrastructure, while internal IT remains responsible for identity, integrations, reporting, user support, governance and coordination with other systems and providers.

How Can an Organisation Reduce Vendor Lock-In?

Document data ownership and export rights, use supported and portable integration methods, maintain current configuration records and agree migration assistance and exit terms before signing. The organisation should retain the information required to operate its reporting and connected systems elsewhere.

Is Managed Hosting Different From a Vendor Cloud?

Yes. A vendor cloud is normally designed around one vendor’s software. Managed hosting can support applications from multiple software vendors while providing coordinated management of the infrastructure, databases, applications, security, monitoring, backups, upgrades and support.