Webflow to Astro for Health Tech

Not by itself, and I am not the right person to tell you that it does. What a migration can do is make the boundary explicit: which pages exist, what each form posts to, and what the analytics collect. Whether anything on the marketing site needs to handle PHI at all is usually the more useful question, and usually the answer is that nothing does. Vendor agreements and the compliance judgment stay with your privacy and security team and your advisers.

It gets looked at rather than copied. A form that posts patient information to whatever the site builder provided is the kind of thing a migration surfaces, because it is the first time somebody traces where each form actually goes. Intake should reach the system chosen to hold that data, and if the current one does not, that is worth knowing before the rebuild rather than after.

The handoffs are rebuilt against the new site. Scheduling widgets, portal logins and intake routes get embedded or linked as before, and each one is tested at its destination rather than at the confirmation screen. If something currently reads patient data before the page is sent, that belongs in your product and I will say so rather than reproduce it.

That depends on what is modeled as content, which is decided before the rebuild. Provider records, conditions, locations and page copy can live in a CMS your team edits. Designing a page pattern that does not exist yet becomes a change in the codebase. Those are different jobs, and the migration is where they are separated deliberately rather than by accident.