How we retired a 15-year-old payment form without hurting conversion

What I took on as PM

• Project management

  setting up the migration project and posting weekly updates in the internal project management system;

• Communication

  setting up communication channels for everyone involved;

• Reporting

  reporting to managers and other stakeholders;

• Team coordination

  keeping teams moving towards the result and resolving cross-team blockers.

Uncertainty and planning

At the start of the project, it became clear that decisions could take too long because many teams had overlapping areas of responsibility. It was not always clear who should join a discussion, who made the final decision, and who only needed an update.

To reduce this risk, I created a map of stakeholders, ownership, and decision making. For each type of question, I wrote down:

• who needed to be involved;
• who made the final decision;
• who needed progress updates;
• what reports to share, how often to share them, and in what format.

The map helped people understand the path to a decision faster. It also helped us see cross-team dependencies that could affect the timeline.

Then we held several meetings with the billing teams, set the main stages, and estimated the resources we needed.

Where the project started to slow down

Dependencies between teams were the main challenge. We could retire the old form only after we updated the payment flows inside the products.

When developers moved to other critical tasks, teams started blocking each other. One team could not continue without the result from another team.

Updating the timeline was another difficult point. To make a new forecast, we had to collect information about developer availability again and compare the project with the quarterly goals of several teams.

Making decisions

To stay on schedule, we defined the minimum amount of work needed to retire the old form completely. We reviewed other problems by looking at user risk, traffic, and the cost of a fix.

We separated the places where this problem could happen. In the payment form, traffic was much higher, so we included the fix in the required project scope. Inside the products, the risk was lower, so we left this part for separate testing through experiments.

Another group of decisions was about cross-team dependencies. In one case, a developer from another team took some of the tasks after offering to help. After that, we agreed on ownership and the order of work again, and the teams could continue the project. I am especially thankful to him for joining work outside his main area of responsibility.

Managing the timeline and risks

We kept the main roadmap in Monday together with projects from the other billing teams. Managers could see dependencies, the current status, and the files linked to each stage.

At the same time, I kept a separate and more detailed project roadmap. It showed what was complete, what we were working on, and what should start next. It helped anyone on the project quickly understand the current context.

• Every week – meetings with developers and Product Owners about progress, blockers, and next steps;
• Every month – a report for all billing teams;
• Every quarter – a shared presentation for stakeholders.

The Head of Product and CPO were the main people who received regular progress reports.

The team stayed almost the same. We agreed early that one developer would do most of the work, while other specialists would join at certain stages. For example, backend developers joined tasks related to PCI DSS. Near the end of the project, we also added specialists who managed setup and releases to pre-production and production environments.

We updated the timeline once. After a new estimate, I moved the forecast by one month and added extra time. We completed technical development before the new deadline.

What we achieved

We retired the old payment form and moved all required flows to the new one. It now supported the main types of purchases, additional and custom offers, trials with promo codes, and payment data updates. We also embedded the new form into upgrade and extra purchase widgets inside the products.

We fixed a critical flow where a user could accidentally replace an existing subscription and lose saved limits. For users with an unpaid subscription, we added a clear warning about what would happen if they bought a new plan.

We now had one form instead of two. Changes to taxes, payment processing, and the interface no longer had to be made twice. It also became easier to find the causes of payment incidents.

Our first attempt to test the new form did not give a reliable result. Data from different metrics did not match. After checking the analytics, we started the experiment again.

We found no statistically significant drop in key conversion rates. After discussing the results with analysts, we released the new form to all traffic in the tested flow. Then we completed the gradual traffic migration and finally retired the old form.

I did not have updated MRR data after we fixed the subscription replacement problem. So I cannot say how successful the fix was. But the main point did not change: we had to migrate the form, and we did it.

What I learned about myself and the PM role

Before this project, much of PM work seemed like a simple series of meetings: collect expectations, write a summary, and agree on next steps with another group. In this project, I saw the value of these basic actions at scale. When several teams depend on each other, shared context, clear ownership, and written decisions directly affect the project’s progress.

It was hard for me to start tasks with a lot of uncertainty, and I noticed that fear made me delay the first steps. It was especially hard to say that the deadline could change and we might need a new estimate. I learned that a PM should raise this kind of uncertainty early enough, even when there is no ready solution yet.

I also learned that a PM does not have to solve every blocker alone. The PM’s job is to make the problem clear, bring the right people together, and create the conditions for a solution. In one such case, a developer from another team offered to help and removed a cross-team blocker.