I’m working on a significant project to migrate apps from on-premises to the cloud, which requires technical reworking of the programs. The business functionality of these apps has not changed at all. How might the epics appear? In the end, they ought to concentrate on the business value, right? However, every one of our stories will be highly technical, involving things like utilizing gradle rather than maven and updating Java versions, etc.
8 Likes
Begin by creating a crosswalk with your lead engineer to identify your on-premises equipment requirements and specifications, as well as what you need from the cloud.
Find out if there are any current issues you can address in the cloud by working with the team. Any database, backup, or autoscaling requirements.
Make sure you collaborate with the team to optimise your branching and release strategies, CI/CD runway, etc.
Work on learning application optimisations and other things as mentioned above.
Using DNS urls and other networking tools, plan your relocation.
Inform your neighbourhood and key stakeholders. IE created a communication strategy. Prepare your downtime communications, relocate everything, and test it all so you only need to repoint the cloud. Voila.
7 Likes
In this scenario, the epics would focus on the overall goals and objectives of the migration project, which may include improving scalability, reducing costs, enhancing security, and increasing performance. The epics should also consider the timeline for the migration project, the resources required, and any potential risks or challenges that may arise.
As the stories for this project will be very technical, it may be more appropriate to create epics that focus on the technical requirements and tasks that need to be completed. These could include things like:
- Refactoring applications to be cloud-native
- Migrating data to the cloud
- Upgrading server infrastructure
- Re-platforming applications
- Updating security protocols and policies
Each epic should have a clear business justification and explain how it will contribute to achieving the overall goals of the project. For example, upgrading the server infrastructure could help improve application performance and reduce costs, while updating security protocols could help enhance data protection and reduce the risk of security breaches.
To sum it up, while the stories for a cloud migration project may be very technical, the epics should still focus on the business value and objectives of the project. By framing the epics in this way, stakeholders will better understand the purpose of the project and the value that it will bring to the organization.
6 Likes
I’ve worked on projects like this before. I wouldn’t worry too much about the appearance of your epics or stories. Refactoring or moving tech stacks, as you indicated, mostly benefits customers through lower costs, increased availability, and occasionally quicker development durations. In my opinion, projects like these require project management of the engineering effort rather than actual “product” work. Actually, before you get engaged or consider switching to another project or product while the migration effort is underway, I’d advise you to consider if you even need to.
5 Likes
Same here, but I developed the product from scratch. Now that it is ready, I am managing the migration program, which, despite its challenges and the fact that we are seeing the benefits and impacts that we predicted in the business case, doesn’t feel like it is effectively utilizing my product talents.
5 Likes
It’s easy to let tech run away with this, but it’s critical that someone is driving the bus on the things that matter for the business. Making sure you can sell your service. There is also a tectonic shift from delivering software on prem and providing a service. It might be lift and shift, but the order that your shift is important for success. In my experience engineering will want to do the cool things before the valuable things in this process.
4 Likes
@GaryHouston I see your point of view but generally don’t agree. There are some scenarios in which PM involvement in a project like this is important (e.g., like you said, are they moving from an on-prem license model to a SaaS subscription model) but given OP said there’s nothing really changing about the app, I’m skeptical. This isn’t a novel process anymore, and there isn’t a ton of ambiguity in decisions to be made that require a product manager. Project manager, yes - making sure there’s a good plan, milestones are being hit, etc.
4 Likes
I know from my own experience that you can’t just lift and shift. To function the way SaaS is expected to, you must alter the product. It involves cost management, pricing, sales, self-service for tasks that you formerly performed in configuration files, deployment, provisioning, updates, and support. The order and acceptance criteria of such conflicting attributes must be managed by PM. Additionally, you’ll need to discuss each of them with your clients.
To do this correctly, you must reconsider a number of your presumptions.
3 Likes
Lift and shift is never a good idea.
Engineers must first receive training in the cloud environment (such as AWS). They are aware that alternatives to operating it in a VM exist.
Second, everyone concerned must be willing to change the infrastructure design and embrace contemporary tools like serverless, which can operate more effectively and affordably but cannot do so by running in a virtual machine.
Ideally, you have access to a cloud architect or other specialist who can help you navigate this process.
3 Likes
I entirely agree that you should employ or contract with certain people who have knowledge of cloud architecture. You require assistance in following tried-and-true patterns.
If you have a working product with market fit that is already on the market, I am not hostile to lift and shift. Before it is finished, a full cloud native rewrite can take years to complete. (I have the T-shirt. Been there, done that. Here you need a lot of feedback loops and evolutionary architecture.
2 Likes
Epics would be something like … Migrate online portal to AWS so that you have reduce capex and improved availability (resulting in better end customer experience) and also have better developer productivity (spinning up resources in cloud is easier) & innovate faster.
1 Like
I’ve completed two of these, and generally speaking, they go like this:
Make it compatible with cloud VMs. Figure out how to make it operate on the cloud largely the same way it does on-premises. Work out details like customer authentication and login. Determine whether you can switch to a multi tenant structure or if you must remain single tenancy. Create your fundamental security model. Determine your observability story because the transition from an on-premise support bundle to “we can see everything” is a significant one.
Start preparing your infrastructure for the cloud. You switch storage from the virtual machine’s discs to something less expensive, such S3 or nvme. Databases are moved to a managed object.
You’ll probably start seeing the things at the same time that customers previously changed by editing configuration files and for which you need to provide self-serve capabilities. This makes the most sense and reacts to areas where you have operational pain while making adjustments for clients. 3a. If you work in an enterprise sector—and I’m going to assume you do if you sell on premises—you probably need some degree of soc or pci certification.
Take steps to implement a true cloud native architecture. You’ll have enough experience to begin using serverless technologies like k8s, containers, auto scaling, messaging architecture, and serverless things to optimize the product as though it had always been in the cloud. Probably things that your engineers needed but you weren’t able to provide for them in your customers’ on-premise environments. 4a. Multi-regional, if your clients are interested in that.
How steadfastly will you maintain parity between your on-premise and cloud solutions is a key concern.
Although it appears laborious and difficult, this is a lot quicker to market and learn than starting over to be cloud native.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.