Keep the data, not the entire app: what to inventory before a refactor

When the brief is “keep the original site’s content, but change the architecture,” the first thing needed is not a component for the new framework. It is a list that lets both sides agree on what must be preserved.

This site moved from Vue to native Astro. Project data, images, and copy in three languages needed to continue, but there was no requirement to retain the entire old app. Rewriting files one by one based on their names can carry unused controls into the new site. It can also preserve the shape of a component while overlooking a URL that readers could previously open.

Start the inventory with the content and behavior readers can see, then trace their implementation. The checklist below is useful for preparing a content-site refactor; it is not a complete migration specification for every kind of application.

References to the site’s current state below describe the implementation and requirements recorded in the original note dated October 5, 2026.

List the content first, then find its source

The first list answers only “what must not be lost.” Do not start by prescribing what kind of component each item must become in the new architecture.

This site’s material included project names, descriptions, external links, images, work experience, and multilingual copy. An inventory should check more than whether the files remain. It should also examine how the actual pages use the data: excluded items, sorting criteria, language versions, and handling of empty values.

The work page recorded here read sorted project data and then excluded some items. “Display all the data” was therefore not the same as preserving the original presentation scope. Data existing and data being suitable for public display are still separate matters.

Check each item:

• Are the data sources complete, and can the meaning of each field still be identified?
• Which items actually appear, and which merely remain in the data?
• Do the sorting and exclusion rules have an established purpose?
• Do the images have corresponding content, and are the external links still entry points that should be retained?
• Is the multilingual content made up of actual versions, or are there fields with no body content?

This pass records the existing state. Mark gaps rather than inventing project descriptions or translations just to make the list look complete.

A feature inventory needs evidence of entry points

When listing a control, include an explanation of how readers find it.

For a project-category switch, for example, identify the entry point on the page and the content shown after switching. For an enlarged avatar view, confirm how it opens, how it closes, and where focus goes. A background animation has no button, but it is still visible behavior; list its animated and static states separately.

During this site’s refactor, a technology filter from an old utility component was added to the new page. It was later removed after checking that the old page had not referenced it. This case gives us an inventory rule: a component file is a clue, not a requirement to preserve a feature.

If no entry point can be found, investigate references and mounting relationships first, then mark the item as “usage unconfirmed.” Do not quietly promote it to a new requirement. Without evidence about other historical deployments, you cannot conclude that those versions did not have it either.

URLs are part of what must be preserved

Even if the page looks similar, losing the ability to open an old deep URL directly is still a change for readers.

When inventorying URLs, record canonical entry points, language versions, and compatibility entry points separately. In the state recorded here, the Traditional Chinese route example /about/work was the canonical URL for the work page, while the old /work remained a readable compatibility entry point. English and Japanese had corresponding routes as well. A compatibility entry point is not a separate piece of content; do not confuse the public identities of the two.

These fields can form a URL inventory:

Field	What to record
Reader entry point	The existing URL and the content it should display
Identity in the new version	Whether it remains the canonical page or becomes a compatibility entry point
Language	The copy associated with the URL and the HTML lang
Page information	The basis for the title, description, and canonical URL
Failure handling	How unknown URLs and content that no longer exists are handled

This is an inventory format, not a statement that every site needs additional languages or compatibility pages. Preserve confirmed entry points rather than creating more URLs to fill the table.

Put implementation responsibilities in a separate column

Once the content and behavior are confirmed, decide what will be responsible for each.

The same requirement can have different implementations. An application’s state can manage the page language, or the URL can determine it. Framework components can assemble a shared shell, or the build can place it in each page’s HTML. Preserve the requirement first and evaluate the implementation afterward, so the old technology does not make decisions for the new architecture.

The division of responsibilities adopted by this site is one example:

Requirement retained	Responsibility in the recorded implementation
Each URL has its own readable content	Native Astro pages and static output
Navigation and language switching	Real links and language determined by the URL
Titles, descriptions, and language information for each page	A shared layout and page metadata
Project data and images	Pages read from the existing data sources
Background animation and local controls	Browser scripts with clear scopes and native HTML

This table describes the site’s choices, not all the evidence needed to establish a successful migration. Its purpose is to identify which old responsibilities no longer need to exist and which requirements still need a new implementation to take them over.

Inventory failure and recovery states for interactions

An animation looking the same while it plays does not mean the whole interaction has been preserved.

This site’s development requirements called for the background streamlines to draw with every animation update in normal motion mode and pause when the tab was hidden. Reduced-motion required a static presentation. The requirements also included redrawing on window resize, cleaning up when leaving the page, and handling initialization after restoration from the browser cache. These states belong in the behavior inventory; “keep the Canvas” is not enough.

Other controls have their own states. For dialogs, list Escape, backdrop clicks, and focus restoration. For images, record dimensions, alternative text, and failure states. For navigation and body content, confirm that they remain readable when JavaScript fails.

Describe expected behavior first, then record verification results separately. Requiring a state to work does not mean it has been tested.

Each item needs a preservation decision, not just a completion check

At the end of the inventory, classify items as: preserve the content, reimplement, confirm separately, or leave out for now. Do not put “needs confirmation” in the “complete” column, and do not automatically classify an unused component as content that can be deleted.

For the technology filter, the supported decision is “not established as a control provided by the original site; leave it out of this refactor,” not “no historical version ever had this feature.” For project data, preserve the data and the confirmed presentation scope without automatically making every record public.

Before rewriting, choose a representative page and take its content, URL, and one interaction through the new implementation approach. Confirm that this increment satisfies the preservation list before expanding to other pages. If a new requirement appears after the inventory, record it as additional scope so that a refactor and a redesign do not become mixed together in a way that prevents acceptance checks.

Scope of this record

This article organizes an inventory method drawn from the site’s refactor and the project presentation, routing, and interaction requirements recorded at that time. The checklists and tables are adaptable working formats, not a complete migration tool. They do not cover login, database migration, or transaction systems. The article does not substitute a preservation list for actual testing, or claim that before-and-after speed, search outcomes, or the features of every historical version have been verified.