Migrating from on premises to PaaS

<< Click to Display Table of Contents >>

Navigation:  » No topics above this level«

Migrating from on premises to PaaS

Overview

By moving to Bizagi PaaS customers receive an isolated private Cloud, that is not shared with other customers. The private cloud contains all of the testing and production environments required, on ready-to-use architecture with no technical or time barriers, that can only be accessed by authorized users. Customers are assigned a unique URLs which are published for internet access.

 

The planning and processes involved in transitioning from an established infrastructure to a PaaS environment must be done carefully to ensure all features are working as expected in the new environment. Your end users will not feel any difference, besides a likely URL change to access Bizagi PaaS applications.

Before you begin the migration process you must make sure you have a detailed plan, that you have fully prepared your resources and you have purchased an Enterprise subscription containing a Testing and Production environments.

 

 

Bizagi PaaS projects

For Bizagi PaaS, default offered environments are Testing environment and Production environment.

 

 

ServiceDescription_01

 

 

 

 

Authoring/development environment

Customers will maintain the existing development environment on premises. Bizagi PaaS will be used for Testing and Production only.

Once applications are built, they can then be deployed to the Testing or Production environments running in Bizagi PaaS. The deployment  is done  via an easy-to-use and web-based UI that only requires a browser.

Deployments need to be coordinated with the PaaS Operations team, with a temporary downtime window that may vary from customer to customer depending on the size of the package, starting from 15 minutes to up to two hours.

 

Testing environment

The Testing environment is used to conduct user-acceptance tests of any number of applications previously built in the development environment.

It is necessary to specify a Performance Level that fits the customer's needs and budget.

 

To identify the Performance Level required for this environment you should analyze the number of BPUs required as well as the storage.

Please review the Performance Level article for more information: http://help.bizagi.com/bizagi-paas/en/subscriptions.htm

BPUs estimation: If you need assistance calculating the number of steps executed in the existing Testing environment, you can use the script attached in Steps query.

Storage: identify the storage used for the existing Testing environment including DB size and the Documents folder.

 

For the migration process, customers need to provide their Testing environment data base as well as their documents folder. The PaaS Operations team will perform the FIRST deployment of the processes and documents, to take all on premises information to Bizagi PaaS. From then on, customers are responsible for the continuous improvement of the developing of applications, and for deploying them in the Testing environment.  

 

Production environment

The Production environment is used to run the automated applications and make them live and available to end users, for production usage.

It is necessary to specify a Performance Level that fits the customer's needs and budget.

 

To identify the Performance Level required for this environment you should analyze the number of BPUs required as well as the storage.

Please review the Performance Level article for more information: http://help.bizagi.com/bizagi-paas/en/subscriptions.htm

BPUs estimation: If you need assistance calculating the number of steps executed in the existing Production environment, you can use the script attached in Steps query.

Storage: identify the storage used for the existing Production environment including DB size and the Documents folder.

You should consider how much the project is expected to grow in the near future. Environments can scale up easily when needed.

 

Similarly as with the Testing environments, for your migration to PaaS, the Cloud Operations team will perform the FIRST deployment of the processes and documents. Form then on, customers are responsible for deploying applications into the Production environment after having verified/ensured that they behave as expected, while using the same web-based UI options for the deployment of applications.

 

Prerequisites

There are some prerequisite that should be verified to certify that a project is eligible to migrate to Bizagi PaaS.

 

Database: migration is enabled for customers using SQL database. Make sure you are running on the SQL_Latin1_General_CP1_CI_AS collation.

Oracle is not currently supported.

 

If the project is NOT in said collation please refer to this article to change it, to make sure the database can be migrated to the Azure database:

Change collation.

 

Bizagi version: migration can be performed for projects in Bizagi .NET version 11.1.

JEE is not supported.

oIf your project is in 10.7 or below, you must first upgrade to the latest 11.0 version and then upgrade to 11.1 version. Your database must be Unicode. If this is your case please contact Support.

oIf your project is in version 11.0 you must first upgrade to 11.1 version.

We strongly recommend that projects upgraded to version 11.1 operate in that version on premises, for a couple of weeks before executing the actual migration to Bizagi PaaS.

 

Work portal styles personalization: PaaS does not support Work Portal personalization such as CSS styles changes or webconfig special keys. If the project makes use of such personalization, they should be analyzed and addressed to provide a workaround for them.

 

What you need to do?

1. Contact us

The migration process requires work from both the customer and Bizagi. Contact us through the support platform to make sure our PaaS Operations team is prepared to guide you through the process.

 

2. Review the PaaS Integration table

Bizagi PaaS supports process applications used on premises, since both use the same process metadata. However, due to cloud's service oriented architecture it is necessary to review each integration in the project, and in some cases, perform adjustments.

 

If the customer's technologies are cloud-ready, all current integrations should be updated to use this approach (preferred alternative).

If the customer's technologies are NOT cloud-ready they may continue using existing integrations such as they are, for which they need to purchase and setup a VPN (this is NOT the preferred approach and it implies additional costs for the customer, on top of the subscription's costs).
For Not supported features the customer should update to the supported options (when available) or delete them from the project before migrating to Bizagi PaaS.

 

note_pin

Consider as cloud-ready, systems and services which are either cloud-native, cloud-enabled or simply published for access through a public channel such as internet.

This means basically a service which has an HTTP/HTTPS (the later preferred) endpoint.

 

3. Consider file attachments

In the event that the customer wants to keep existing production cases, consider that Bizagi PaaS does not handle case attachments in file servers.

In such case, it will imply that you need to anticipate to how much storage will case attachments demand, so that you can consider an appropriate BPU level.

This analysis is important in terms of preparing a migration to a staging or production environment.

In order to conduct the analysis, you may rely on the File Migrator Tool as instructed at the Moving file uploads into the database document.

 

PaaS Integration table

The following table lists all the integration features to be taken into account, and the adjustments required, to comply with the cloud's technologies, before migrating.

 

CATEGORY

FEATURE

OPTIONS & PARAMETERS

ACTIONS REQUIRED

Identity and access Management and Authentication

Runtime authentication

(refer to Authentication below)

Azure AD

Supported.

No action required.

Bizagi

Supported.

No action required.

OAuth

Supported.

No action required.

Federated

Supported.

No action required.

LDAP

Supported.

Action required: setup a VPN.

Windows

Not supported.

Mixed:

Windows + Bizagi

Not supported.

Custom

Not supported.

Mixed:

Custom + Bizagi

Not supported.

Importing users from LDAP

Via LDAP protocol.

Supported.

Action required: setup a VPN.

Performance considerations.

Data integration

Replication

(refer to Replication below)

MS SQL Server

Supported

(same on-premises SQL Server versions supported).

Action required: setup a VPN.

Performance considerations.

Oracle

Not supported.

Custom (other DBs)

Not supported.

Virtualization

(refer to Virtualization below)

MS SQL Server

Supported (same on-premises SQL Server versions supported).

Action required: setup a VPN.

Performance considerations.

Oracle

Not supported.

Custom (other DBs)

Not supported.

Application integration

Service-based

WS Connector

Supported - if cloud-ready.

No action required.

If not cloud-ready requires VPN setup  Performance considerations

Bizagi Connectors

Supported (preferred).

No action required.

ECM integration

 

Supported - if cloud-ready.

No action required.

(same on-premises ECM products supported).

If not cloud-ready requires VPN setup  Performance considerations

Point-to-point

SAP Connector

Not currently available.

Component library (view topic below)

Supported for self-contained components.

Custom Jobs

Supported.

No action required.

Others

Widgets

Supported.

No action required.

Using Bizagi from external applications

Bizagi SOAP Web services API

Legacy Web services

Supported - if cloud-ready.

No action required.

If not cloud-ready requires VPN setup Performance considerations

WS-Security Web services

Supported

Bizagi Web parts

SharePoint Web parts

Supported for SharePoint online.

No action required.

SharePoint on premises requires VPN setup Performance considerations.

Web parts for any portal

Supported if cloud-ready

No action required.

(same on-premises portal products supported).

If not cloud-ready requires VPN setup Performance considerations

Email services

Email server

Via SMTP protocol.

Supported.

Bizagi PaaS includes its own email service. Customers need to adjust settings in Bizagi Studio and Management Console provided by PaaS Operations.

Email integration in forms

Exchange

Supported if cloud-ready.

No action required.

If not cloud-ready requires VPN setup  Performance considerations

POP3

Not supported.

IMAP

Not supported.

Others

Database configuration

ODS

Not supported.

Column level encryption

Not supported.

Utilities and resource kits

Management Console

Supported via Web UI.

Certain options which handle servers and clusters are not applicable, as well as others regarding configuration of underlying infrastructure.

Automatic Testing

Supported

Deployment

One-click Deployment

Not applicable due to infrastructure differences.

Advanced Deployment

Deprecated: superseded by the Export bex feature to deploy in PaaS environments.

 

VPN setup

With Bizagi PaaS, it is entirely optional to use a VPN and it would be needed for integration purposes (i.e. integration with LDAP, DB sources via Replication or Virtualizationn, ECM not cloud ready, or integrations with systems of record), whenever the applications you want to integrate with, do not offer a service-oriented architecture and use different protocols other than HTTP/HTTPS.

We encourage you to expose all your systems in a demilitarized zone, where Bizagi could integrate without the need of a VPN.

 

A VPN setup adds an additional cost to the subscription costs.

 

For more information about VPN setup, refer to Cloud VPN.

 

 

Authentication: Bizagi PaaS supports integrating with Identity Management services such as the Open ID Connect protocol. The following authentication methods are supported:

oAzure Active Directory (Azure AD)

oLDAP (this integration requires VPN setup)

oBizagi.

If you have any other authentication method, it must be analyzed. For more information refer to Identity managers.

 

Virtualization and Replication

Data Virtualization and Replications entails some aspects you will need to consider. When integrating an on-premise data source via data Virtualization, Bizagi PaaS will connect to it through its assigned TCP service port, and therefore, you will need a VPN to allow such communication and to implement it with due hardened security measures.  

Access to an external data source over the internet, inherently depends upon different factors which are beyond Bizagi PaaS' control, such as: a higher latency in data transmission, fluctuations, interference and congestion affecting the speed of the channel, the quality of the networks used during transmission, etc. All of these factors may affect the overall user experience, and therefore, you will need to mitigate them. Refer to Data virtualization.

 

Component library

Supported, through consider that you are solely responsible of the code developed in custom components added through this feature.

This entails: watching after an adequate performance while ensuring that locks or issues are not generated, being accountable for uploading secure code, and ensuring that such code is thoroughly tested throughout the different environments, among others.

 

Consider that components must be self-contained (i.e, all libraries needed by a component must be uploaded via the component library). This means that a component may not rely on driver, DLL, file in general, or connectivity setup that needs to be installed separately into the local machine.

 

Recall that Bizagi PaaS, as a cloud-centric architecture, is built for scalability among other pillars.

A high scalability in Bizagi PaaS considers that computing power, storage services and other capabilities, are made available on-demand as elastic resources which operate behind a load balancer, and therefore, point-to-point integrations which demand the installation of a component in a specific location is not a best practice.

For this reason, it is important that when integrating your systems and services you can follow modern and service-oriented principles such as using Connectors when applicable.

For more info refer to Bizagi Connectors.

 

Deployments

Deployments in cloud environments are performed differently than in on premises projects. Neither one-click-deployment nor Advanced deployment are used.

Please ensure that Customers are familiarized with the cloud-based deployment process described in this article: Export to Cloud.

This understanding is vital to guarantee  the continuous improvement in migrated projects.

 

New URLs

One lingering question is how the transition to Bizagi PaaS will affect an organization’s URLs. Once your application is running in Bizagi PaaS, each environment will have separate resources which translate into an independent URL, as described below.

Test environment: http://test-projectname-company.bizagi.com

Production environment: http://projectname-company.bizagi.com

 

If the customer uses the mobile application the project's URL should be updated as well, using the same URLs for desktop access.

 

It is necessary to inform this change to the customer's organization with due time.

 

Case links

Your SMTP configuration needs to be changed to adapt to Bizagi PaaS setup. The Cloud Operations team will send you instructions to adjust the SMTP server information in all your environments.

 

Users and access rights

Moving to Bizagi PaaS will require the creation and delegation of users to be administrators of the subscription. These users will be able to monitor resources, and make the actual deployments to the Testing and Production environments.

All end users should have their own unique email. Email duplicates are not supported in Bizagi PaaS.

Users and groups will be exactly the same as in on premise application. No additional configuration is required.

It is highly recommended that customer's administrators take the cloud administration training course, prior to the migration to Bizagi PaaS.

 

About performance considerations

For those features where there are performance considerations, you will need to take into account certain aspects relevant to your network communications, application design, testing and tuning overall. This applies when connecting to on-premises systems via a VPN.

Given the nature of a cloud-based service where the communication from your premises to the cloud inherently depends upon factors which are beyond Bizagi PaaS' control (such as a higher latency in data transmission, fluctuations, interference and congestion affecting the speed of the channel, the quality of the networks used during transmission, etc), you will need to make sure that the use you give to certain features is appropriate for the specific requirements of your applications.

 

About service-based integration

Recall that it is strongly recommended to rely on a service-oriented architecture in order to make the most of your Bizagi PaaS implementation.

The VPN alternative is strictly optional and furthermore, it is not the recommended option.

Through a best practice such as a service-based integration, you achieve greater maintainability and scalability among others, and also promote a better system architecture over the one entailed in point-to-point communications.

 

 

 

 

 

Moving to Bizagi PaaS

 

Testing and Staging environments

It is important to verify that existing applications behave as expected in the new environments. The tests will get you familiarized with the migration process, and more importantly, you will become aware of any problems so that they can be properly handled during the production migration.

 

Moving the Test and Production databases, as well as your files, from on premises to Bizagi PaaS is done exclusively by Bizagi 's support team. We require that you hand in a copy of the production database and a copy of all files (uploaded and generated) to deploy all existing data to Bizagi PaaS.

Note: Files will no longer be saved in a file server, but in a blob storage. If your files are in an external ECM system, the files will not be moved.

 

Remember that all cloud-based solutions inherently depend upon different factors such as: a higher latency in data transmission, fluctuations, interference and congestion affecting the speed of the channel. Make sure you test your solution and guarantee that the Performance Level chosen responds to your needs.

 

1. Perform end-to-end tests in the PaaS Testing environment

The first step is to deploy your on premises Testing environment to your new PaaS Testing environment. Tests in this environment will guarantee that the application run smoothly, all integrations work correctly and documents are uploaded and displayed correctly.

To do so, backup your Testing environment, and send it to our Support team. Keep in mind that in this step there is no downtime in your on premises setup.

 

2. Perform end-to-end tests in the Staging environment

The environment you use for the actual migration testing should be similar to the Production environment.

Thus, Bizagi will temporarily prepare an Staging environment, with an environment similar to Production, where the production database is to be used, to guarantee that the transition is smooth.

Once customers have fully tested and certified their application running in Bizagi PaaS this environment will be deleted and will be replaced by the official Production environment.

 

PaaS Operations should receive a backup of the customer's Production environment. In this step there is no downtime in the on premises setup.

 

3. Move to PaaS Production environment

When the customer has fully tested and certified their application running in Bizagi PaaS:

3.1 Decide a non-working-date in which the on premises system can be turned off, to completely move to PaaS. Coordinate such date with Bizagi's PaaS Operations team.

3.2 On the specified date shut down the on premises application; otherwise end users will continue working on it and information will be lost.

3.3 Take a backup of the Production environment and all documents and send them to PaaS Operations. We strongly recommend to send these backups at the end of the day in order to have your Production environment ready on the next working day*.

3.4 PaaS Operations team will deploy the backup to the PaaS Production environment.

3.5 Perform final testing with a group of selected users.

3.6 Inform the organization and go live.

 

 

note_pin

*Downtime subject to the size of the database and files sent