Cloud Options for Pega Customers

In our previous article we discussed why it is now the moment to move your Pega running on VM to the cloud. Let’s recap why:

• to reduce technical debt
• to achieve business agility and
• to stay competitive

It’s about getting your business ahead, not just maintaining the status quo.

So what are the options you may ask? You have 2 options!

And which one you should choose? Well, it depends.

• Option 1: move to Pega Cloud.
• Option 2: containerize Pega and move to your own data center, or host in Public Cloud (AWS, GCP, Azure)

Let’s summarize the features and pros/cons of each one.

Moving to Pega Cloud

Don Schuerman, Pega CTO, put this succinctly: “Let Pega take care of infrastructure, managing it, upgrades, security, scalability while you concentrate on business outcomes”

Here Pega runs all the services and infrastructure to deploy and manage your Pega instance(s) and solutions. It’s like renting office space: you own some space, have elasticity (offices on demand), and can adjust your usage based on workload (fewer people in the office, remote work, hybrid policies, or peaks). The office space owner takes care of everything else.

With Pega Cloud you might lose some control over your Pega stack, but your team can focus solely on Pega. Your company’s IT team doesn’t need to be involved in continuous operations, as Pega handles:

• Operational support and monitoring
• Fault tolerance, backups, and restores
• Fully scalable environments
• Continuous patches and upgrades
• Hardened security

Pega has been doing these for many years, and they have a strong team to manage their client environments and you can trust them. Pega offers deployment choices on AWS or GCP, dealing with the underlying infrastructure for you.

This option is convenient if you want to focus on app innovation and serving your end users with an experienced Pega team.

On the contrary, if some of these conditions are more critical, consider migrating to a self-managed infrastructure:

• Your workloads are predictable, and peaks are very rare
• Your Pega apps heavily integrate with internal systems

Other important considerations include your IT strategy to move to more agile infrastructure (usually a hybrid approach), avoiding public cloud vendor lock-in, or maintaining independence.

Your workloads and integration with internal systems can significantly influence the final TCO of your migration project.

With predictable workloads, running on your self-managed Kubernetes environment could be more cost-effective, assuming your company has a mature one in place.

Finance, compliance, and legal considerations are crucial factors:

• Renting a solution long-term could be more expensive than owning it
• Compliance and legal requirements can be the key decision factors

Considerations when moving to a self-managed infrastructure

If you’re currently running Pega on VMs, you’ll need to run Pega on Kubernetes/containers. Fortunately, Pega Infinity already runs on Kubernetes, and Pega supports this option:

• Run where you want – our cloud or your cloud
• Customize what you want, without being constrained by limits
• Move from your cloud to ours, vice versa, or even on-premises

In this scenario, your Pega team collaborates with your IT team to manage the infrastructure and details, similar to your current VM setup.

If you have a strong IT team experienced in deploying Kubernetes-based solutions, this option provides extreme customization and flexibility to define and manage the full stack according to your business requirements.

This approach offers independence from decisions made by Pega and the cloud provider that could affect infrastructure services and your Pega deployment, including pricing changes.

You can continue using the same integration infrastructure to connect with the applications your Pega solutions orchestrate.

Compliance, legal, and data residency are under your control.

With predictable workloads, this option could be more cost-effective than being in the cloud, as you don’t need to scale instantly for peaks.

Your IT team won’t disappear in the migration to the cloud. They should understand how to deploy Pega in Kubernetes, and we can help with that!

In summary, consider taking full control of your Pega deployment if you have:

• Predictable workloads
• Heavy integration with internal systems
• Strict data residency, legal, and compliance rules

This approach will save you long-term costs and align with your company’s IT strategy.

How Process360 can help you

The migration process includes an assessment of your current deployment to:

1. Decide between Pega Cloud or self-managed, as discussed in this article
2. Evaluate how to migrate your apps from Pega VM to Pega on Kubernetes, regardless of your choice between Pega Cloud or self-managed

If you choose self-managed, Process360 combines deep experience in Pega with extensive Cloud and Kubernetes skills. This is crucial for effectively discussing how to deploy Pega on your Kubernetes environment with your IT team.

However, migrating your apps to the Cloud or self-managed is not that straightforward. Here’s a quick recap of your options:

Lift and move

Upgrade to the latest version, export/import the app into your Pega Cloud instance, and thoroughly test. Pega provides tools, and Process360 adds deep experience to quickly identify low-hanging fruits for migration.

This works well for Pega apps implemented using the latest best practices and with simple or no integrations with other applications.

Refactor

There’s more to do, such as losing direct database control and avoiding shortcuts like views for reporting. Review your UX/UI, move legacy apps to Pega Cosmos-Constellation, and migrate deprecated rules to new versions or recreate functionality.

Pega Upgrade Tools and Docs help, and partnering with Process360 makes this process smoother.

This applies to Pega apps with accumulated technical debt and API-based integrations.

Modernize

Sometimes, completely redesigning the app is the best option.

This could happen for apps developed long ago, tweaked over time, and heavily integrated with systems not using API-based integrations.

It’s an opportunity to review and modernize your processes. While challenging for critical apps, Pega BluePrint GenAI can accelerate the discovery and design phase.

Ideally, focus on your most important app.

Don’t forget what’s outside Pega!

If your Pega app integrates with on-premises solutions that haven’t been upgraded for cloud integration, there’s more work to do.

Process360 is here to work with you. Contact us today for a free consultation and assessment of your specific requirements and goals to start your Pega cloud migration journey.

TL;DR

Why Explore Both Options: Pega Cloud or Private Cloud?

• Tailored Solutions: Align Cloud deployment with your unique business needs, regulatory requirements, and cost considerations.
• Control and Customization: Choose Private Cloud for greater control over infrastructure and costs, especially when Public Cloud isn’t the best fit.
• Consistent Deployment: Benefit from consistent, API-driven environments that accelerate development and reduce latency.

Drivers of your Cloud choice

Why Process360:

• Expertise and Experience: Our team boasts over a decade of Pega and cloud solutions expertise, ensuring a seamless migration process.
• Comprehensive Strategy: We conduct detailed assessments to tailor migration plans that align with your IT strategy and business goals.
• Best Practices and Support: Expand your CoE with our guidance on deploying Pega using best DevOps practices, ensuring faster, more reliable implementations.
• Partnership Approach: We collaborate closely with your team, offering training and support to maximize your cloud investment.

Process360 can solve your Cloud Modernisation challenges

References

• Pega Community: Explore Pega Cloud
• Pega Docs: Learning about Pega Cloud
• Pega: Don Schuerman why Pega Cloud at Pega Cloud
• Pega Trust
• Understanding the Pega deployment architecture
• Why we are leaving the cloud

Quotes

David Hansson: The main difference here is the lag time between needing new servers and seeing them online. It truly is incredible that you can spin up 100 powerful machines in the cloud in just a few minutes, but you also pay dearly for the privilege. And we just don’t have such an unpredictable business as to warrant this premium. Given how much money we’re saving owning our own hardware, we can afford to dramatically over-provision our server needs, and then when we need more, it still only takes a couple of weeks to show up.