How to use Cursor to migrate a memorial media site
Emerson used Cursor to move a family memorial site from vanilla JavaScript to Next.js and Supabase, handling accounts, permissions and Vercel setup himself.
humangoodkinddesigns.com
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Migrate [vanilla JavaScript media site] to [framework] with [database and storage]. Inspect the current media experience, refactor components and connect content management. List required account, permission and environment-variable setup for me to complete and review.
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Grant Emerson
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- Family memorial site live at fje-memorial.vercel.app.
- Human involvement
- Author chose architecture and handled accounts, environment variables, storage permissions and service connections.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Used existing vanilla JavaScript site as project context.
- Cursor scaffolded/refactored Next.js components and wired Supabase storage/tables.
- Configured Vercel and Supabase deployment plumbing.
Grant Emerson used a family memorial website as a practical Cursor project. The site collected music, video and other work by his father-in-law. Its original version used vanilla JavaScript and direct DOM manipulation, but adding new media without editing code required storage and dynamic content management.
Emerson chose a Next.js application backed by Supabase database tables and file storage, deployed on Vercel. Cursor worked with the existing project context to scaffold components, refactor the old implementation and connect the media hub to the new backend. The article reports that these coding changes moved quickly across the project files.
The surrounding service setup was slower. Emerson created and configured accounts, connected environment variables, worked through storage-bucket permissions and made sure deployment reached the intended services. Those steps remained part of his work rather than an invisible consequence of code generation.
The resulting memorial site is available on Vercel. Emerson describes it as both a family project and a way to refresh his full-stack skills; he also acknowledges that Next.js was more architecture than a small memorial strictly needed.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Blog · Grant Emerson
Frequently asked questions
Why replace the original static implementation?
Emerson wanted dynamic content management and file storage so new music or video could be added without changing the codebase.
What stack did the migration use?
The account names Next.js App Router, Supabase for database and file storage, Vercel hosting and Cursor as the development tool.
What still took human setup work?
Accounts, service projects, environment variables, storage permissions and deployment connections took a meaningful share of the work.
More details
About this account
Cursor scaffolded and refactored the application across files and connected media components to Supabase; service setup remained human work.
Primary first-person account opened and checked on 2026-10-14. Account/infrastructure setup took longer than code migration. Outcomes and test claims are attributed to the source and were not independently reproduced. Prompt is suggested by Agents In Use, not the author's quoted prompt.
Credit: Grant Emerson on Blog
Source published
Added to Agents In Use
Source checked
Tools and topics
Cursor · Next.js · Supabase · Vercel
Family archive · Site migration · Media storage
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.