Connect `/move` plans to migration flows

[fditrapani]

Problem

If you visit /move and click on one of the plan CTAs, we take you through to the regular onboarding flow.

Clicking on any of the CTAs takes you here:

Ideally, we'd take you to checkout to pay for the plan and then through to the migration flow where we ask for your address or platform:

Where

• Visit wordpress.com/move
• Scroll down to the plans
• Click on one of the Plan options

[github-actions]

OpenAI suggested the following labels for this issue:

• [Feature Group] Plans & Upgrades: The issue relates to how plans are presented and upgraded during the onboarding flow.
• [Feature] Checkout: The issue discusses the checkout process when users purchase a plan after clicking a CTA.
• [Feature] Site Migration: The goal is to integrate migration flows after users select a plan, highlighting site migration aspects.

[fditrapani]

@AtrumGeost @jrdnhllr I found this legacy issue on the old /move page and see we still have it on the new one. Any chance we can get this flow updated?

[niranjan-uma-shankar]

@fditrapani we have a similar issue with fragmented hosting signup flows in /hosting LP, which I documented here p58i-keE-p2#comment-66947.

On any landing page, clicking on a plan CTA in the pricing grid leads to a "plan-specific" signup flow which adds the selected plan to cart. The domain step is shown, plan step is hidden (since the plan is already selected and in cart), and then we go to checkout.

The steps that you mentioned, which is click plan CTA -> maybe account creation? -> checkout -> migration flow, is better handled by the team that built the migration signup flow. Going by this post pbxNRc-4Ek-p2, looks like it might be Team Serenity?

I see that in the hero section of /move, we don't even allow the user to signup if their site is not eligible.

In the flow that you proposed, we'd be allowing the user to signup AND pay for the Business plan, and then we'd let them know their site is not eligible. Could that lead to increase in support requests or some unhappy users? If yes, then maybe the flow could be plan CTA -> evaluate eligibility -> signup -> checkout -> rest of the migration flow.

The current migration flow (when you enter an eligible site in /move) has a bunch of steps even before the plans page is shown. Do we need any of these in the proposed plan-specific flow?

These are probably some questions better answered by Serenity, or whichever team is more intimately aware of this flow. Maybe we can take the cause of both /hosting and /move together, so that the pricing grid CTAs lead to the appropriate flow. The current plan-specific flow is definitely not appropriate on these landing pages.

[fditrapani]

Thanks for the background @niranjan-uma-shankar. Serenity does work on the migration flows. I, or someone on the design team, can spend some time mapping out the ideal flow before we bring them up.

In the flow that you proposed, we'd be allowing the user to signup AND pay for the Business plan, and then we'd let them know their site is not eligible.

That's right. I guess that's happening now already. Some of the ideas you proposed could work (ie taking people into the migration flow to validate their URL first). Another approach is making it more explicit that this is for WordPress migrations. This maybe speaks to a larger issue on the page about making that distinction clearer. Again, that's something we can dive deeper into when we look at the design aspect here.

[niranjan-uma-shankar]

Hey @fditrapani , do we have an ideal flow mapped out for this yet?

[fditrapani]

@niranjan-uma-shankar here's what I'm thinking for an ideal flow, let me know if it works:

1. Go to Create an account if not logged in.
2. Go to checkout.
3. Take people to /setup/hosted-site-migration/site-migration-identify.

From there we would recognize upgraded site and not ask to upgrade in the migration funnel again.

I think we'll also need to create a new site between steps 1 and 2 but that should be done in the background and not by going through the onboarding steps.

Now that I've documented the ideal flow, I will caveat that this looks and smells like a custom flow :D I know we want to get away from those. I could be wrong through, do you know if we have existing infrastructure to support this? For checkout, I know we can use the redirect_to= URL to send people somewhere after but don't know if we can create a site before getting to checkout.