The cloud environment is hosted in Microsoft Azure, a cloud computing platform hosted across many data centers across the world. This overview briefly discusses some basic concepts related to the cloud environment and introduces some common terms. For a more comprehensive list of terms, see Terms & language.

Resource groups are collections of resources, which are billable items that include virtual machines (VMs), disks, storage accounts, services, backups, IP addresses, image snapshots, licenses, and more.

Environments are how resources are organized within a resource group, typically for a specific purpose.

Environments

At ASI, Azure resources are organized into one of the following three environments:

The development environment, used for development work such as building, configuring, and validating functionality outside of Production. Development sites (which are optional and available for purchase) are hosted here.
The staging environment, used for pre-production implementation and testing. Staging sites mirror the production environment as closely as possible.
The production environment, used for live, public-facing client iMIS sites (also called production sites).

Development environment

The development environment contains all resources used for building, configuring, troubleshooting, and validating functionality. Development environments reside on Cloud Development servers and provide safe spaces for teams to experiment, prototype, and verify changes without impacting live systems.

Development sites are also referred to as UAT, BPV, or Sandbox sites depending on their use. Development sites are optional and are not part of every client’s setup.

A BPV (Business Process Validation) site is a specialized environment used exclusively by ASI’s Client Success team to validate end-to-end business processes before a client goes live. Unlike other development environments, BPV sites reside on Internal Staging servers.

Staging environment

The staging environment provides a controlled, pre-production space where teams can validate a site's overall functionality, visual design, integrations, and user experience as they will appear in the live environment. Staging environments run on Internal Staging servers and are intended to mirror the production environment as closely as possible.

In the staging environment, staging sites exist for clients who are testing systems prior to going live on iMIS EMS. Typically, staging sites are for clients who upgrade from iMIS 2017 or for clients who are new to iMIS. When a client is actively building and configuring their Staging site, this period is often referred to as the implementation phase, during which the client and internal teams collaborate to prepare the site to go-live. Staging sites operate under a BETA license and do not have custom domains.

Once a client goes live, their staging site is removed 2-4 weeks afterwards. If you want to keep your staging site, you can convert it to a development site for an additional cost.

Production environment

The production environment contains all resources for live, public-facing client operations, known as production sites. This is the environment accessed by end users and serves as the fully operational instance of iMIS for all ASI clients. Production sites operate under a LIVE license.

Requesting a development site

As an iMIS client, you may have a development site included in your initial purchase, or you can request one separately. A development site (also known as a dev site) is a development environment copy of your production site’s database.

Review the following key details about development sites:

A development site can be purchased during implementation or after go-live.
Clients may purchase multiple development sites.
Each purchase includes a one-time setup fee and an ongoing monthly fee for as long as the development site remains active.
Custom domains are not supported in development environments.

A database refresh is a related service that updates a development site by replacing its data with a current copy of the production database. Clients typically request a database refresh when they need their development environment to reflect the latest real-world data for testing, troubleshooting, or development purposes. Each database refresh incurs a separate fee.

For a full list of Cloud Services billable services, including additional domain purchases and dry-run upgrade environments, see Billable services.