Hiring a Webflow to Astro developer: eight questions to ask

A useful migration proposal explains what will be preserved, what will be rebuilt and how the result will be checked. The framework choice is only part of that explanation.

These questions help you compare developers on the work itself. They are useful whether you hire a specialist, an agency or somebody already on your team.

Eight questions worth asking

1. What are you using to define the scope?

Ask for the inputs: pages and templates, content models, interactions, custom code, integrations and known URL history.

Page count is useful, but a list of templates does not capture everything either. A small site with difficult integrations can require more work than a large site with repeated layouts.

Ask to see: the inventory, assumptions and exclusions behind the estimate.

2. How will marketing publish afterward?

Ask the developer to walk through an actual copy edit and a new page. Clarify what marketers can change, what requires a developer and whether previews are included.

A configured headless CMS can support visual editing and page composition. Do not accept either “everyone must edit code” or “marketing can change everything” without seeing the intended setup.

Ask to see: an example publishing workflow using your likely content model.

3. What happens to the URLs and search metadata?

The answer should distinguish addresses being kept from those changing or being retired. It should also explain how titles, descriptions, canonicals, internal links and relevant structured data will be checked.

Ask to see: a sample URL inventory with intended outcomes, not only a list of redirects.

4. What is the content migration plan?

Find out how records, relationships, rich text, assets and publication states will move. Ask what happens to edits made while the rebuild is underway.

Ask to see: a field map, representative converted records and a reconciliation report.

5. How will interactions and integrations be handled?

A developer should identify the behavior being preserved and the implementation being chosen. Retaining a runtime and rebuilding an interaction are different approaches; either needs an explicit reason and testing.

For forms and analytics, a visible success state is not the final check.

Ask to see: evidence that a test reaches its destination with the expected values.

6. What must pass before launch?

“Quality assurance” is too broad on its own. Ask what is automated, what is reviewed manually, which browsers and devices are covered, and who signs off the result.

Accessibility, consent behavior and important user journeys should be part of the discussion, not assumed to follow from a successful build.

Ask to see: acceptance criteria and an example check record.

7. How will cutover and recovery work?

Ask who controls the hosting and DNS, when the final content update happens, what production configuration is required and what triggers a rollback.

A rollback is not just putting old files back. Content edits and new form submissions may also need to be accounted for.

Ask to see: a launch sequence with responsibilities and a recovery plan.

8. What does your team receive after launch?

Clarify repository access, provider accounts, documentation, training, included aftercare and any optional support arrangement. The project should not end with code that only the original developer knows how to run.

Ask to see: the handover deliverables and the boundary between included fixes and new work.

Compare responsibility, not team size

A solo specialist can offer direct continuity. A team can provide additional capacity and coverage. Neither model guarantees a better migration.

Compare relevant experience, communication, availability and ownership of the checks. Look for somebody who can explain a tradeoff without turning every alternative into a mistake.

Send candidates the same brief

Comparable proposals start with comparable information. Give each candidate the same site URL, business goals, known integrations, content types, publishing requirements and desired timing. Explain whether the visual design should stay the same and whether any content is being rewritten.

If you do not yet know the full inventory, say so. A developer may reasonably propose discovery before committing to a fixed scope. The useful question is what that discovery produces and how it informs the later decision.

A short brief should identify the current problem, the desired outcome and the constraints. “Move to Astro” names a technology. “Let marketing publish approved landing pages while engineering reviews component changes” describes a result that can be demonstrated.

Evaluate evidence rather than confident answers

Ask for artifacts that show how the developer works. A redacted inventory, example field map, launch checklist or handover document can reveal more than a broad claim about experience. The artifacts do not need to expose another client's confidential information.

Look for a connection between the scope and the checks. If the proposal promises content preservation, the developer should explain reconciliation. If it includes integrations, the checks should reach their receiving systems. If it promises editorial independence, there should be a clear demonstration of ordinary publishing.

The purpose is not to demand a complete unpaid migration design from every candidate. It is to understand the proposed method and identify what must be settled during paid discovery or implementation.

Use one representative task in the discussion

Choose an article with an author reference, an image and a public URL. Ask the developer to explain how it would move and how they would prove the result is correct. Then ask how an editor would publish another article afterward.

This small exercise connects content extraction, destination modeling, routing, rendering and publishing. A good answer should identify decisions and uncertainties without pretending that every project is identical.

For a lead-generation site, add a form example. Ask what confirms that campaign information and required fields arrive in the destination. For a multilingual site, ask how translations and locale-specific routes stay related. Tailor the discussion to the work that carries risk in your project.

Avoid making a puzzle or trivia test out of the interview. The goal is to evaluate practical judgment, communication and ownership of the outcome.

Agree milestones around reviewable results

Milestones should represent something the client can assess. An approved inventory, a working representative template, a reconciled content import and a verified production release are more meaningful than a percentage-complete statement.

For each milestone, record the evidence, who reviews it and what happens if there is an unresolved exception. The payment arrangement can then follow the actual agreement rather than a vague expectation that the whole site will be ready at the end.

Also name the inputs the developer needs from you. Access, content approvals and decisions about retiring features affect delivery. A clear proposal identifies those dependencies without using them as a blanket excuse for every uncertainty.

Clarify ownership and support before launch

The business should know where the code lives, who owns provider accounts and how access will be transferred or maintained. A handover should make it possible for an appropriate replacement developer to understand and operate the site.

Ask what the initial aftercare covers. Fixing a migration defect is different from designing a new page after launch. Search monitoring, dependency updates and ongoing content support may have separate owners and arrangements. Put those boundaries in writing so the launch does not create an unexpected support gap.

Recovery deserves the same clarity. The team should know who can restore a previous release and how new content or submissions are handled if a rollback is needed. A backup that nobody knows how to use is not an operational plan.

Compare proposals using a written decision record

After the discussions, write down what each candidate includes, excludes and leaves unresolved. Compare the expected result and the confidence of the scope, not only the price. A higher quote may include work another proposal omits; a lower quote may reflect a genuinely simpler approach.

Ask candidates to clarify material differences before making the decision. If one proposes retaining a runtime and another proposes rebuilding an interaction, ask each to explain the maintenance and verification implications. There can be more than one defensible implementation.

Choose someone whose process makes difficult decisions visible and whose handover fits the team that will operate the site. The cost guide explains scope differences, and the migration checklist provides a concrete basis for acceptance criteria.

Get the agreement in writing

The scope should connect deliverables to acceptance criteria, price, assumptions and dependencies. Unresolved decisions should be named rather than buried inside an optimistic timeline.

I provide Webflow-to-Astro migrations, so this is also how I want my own proposals evaluated.

Get a scoped migration estimate.

Sources

• Sanity: Visual editing. Checked September 18, 2026.