Local-first assessment Account save for existing users

Stabilize or Rebuild?

Decide the safer first move for an aging PHP, CMS, ecommerce, portal, or admin system that still runs important work.

Answer the system as it exists today, then get a practical recommendation, plain-language rationale, risk map, and next-step list. Rebuild is one possible outcome, not the default.

  • Directional first-move recommendation
  • Why it fits the current situation
  • Main risks to address before bigger scope
  • Copyable and printable report summary

You need a grounded first direction before promising a migration or rebuild plan, especially when backup confidence, hosting reality, or workflow fragility are still partly unclear.

Start with what is true today, including uncertainty. Unknown backups, unclear hosting, or fragile repeated work are often the reason to slow down before promising bigger change.

Looks at

Technical fragility, operational workarounds, backup confidence, data clarity, and how safe bigger change would be right now.

Returns

A practical first-move recommendation with rationale, risks to address, and what to gather before asking for help.

Does not do

It does not replace technical discovery, promise exact effort, or push you toward a rebuild by default.

Stabilize Wrap Migrate Rebuild

The recommendation explains which of these is the safest first move right now, and why. “Wrap” means keeping the old system running while moving fragile repeated work into safer workflows around it.

0 of 23 question groups answered. Start with the facts you know. Uncertainty is part of the signal.

Coverage 0%
0%

The report unlocks after at least 6 answered question groups.

Honest partial knowledge is more useful than polished guesses. Unknown backup, hosting, or publishing details usually justify a steadier first move.

Guided assessment Not sure is a valid answer

Map the current reality

Work through the parts you can confirm today. Unknowns around hosting, backups, recovery, or update workflow are useful signals, not mistakes to hide.

Start with the parts you can answer confidently. You do not need every fact upfront for the form to become useful.

Report unlock

6 more answered question groups unlock the first-move recommendation.

Best approach

Pick the closest description of how things work now, not the cleaned-up future state.

Next useful section

System context (0 / 4 answered)

Move in order or start where the facts are easiest to confirm.

0 of 23 question groups answered

Focus here next

System context

What kind of system this is, roughly how old it feels, and whether the knowledge to change it safely still exists.

What best describes the system today?
Choose one

Pick the closest fit. This is about how the system is used, not what someone wishes it were.

Pick the closest answer.

How well understood is the current platform or stack?
Choose one

This is about how much the underlying system has been modified from its standard base. A stock WordPress install is very different from one with years of custom code layered on top. If nobody is sure what has been customised or added, pick the last option.

Pick the closest answer.

How old is the current system, roughly?
Choose one

Rough estimates are fine. Age matters because older systems tend to accumulate undocumented dependencies and unsupported software, not because old automatically means broken or ready to replace.

Pick the closest answer.

Who can still explain how this system really works?
Choose one

Think about who could walk someone through the deployment process, explain what the database holds, or identify what breaks when the system is updated. General familiarity is not enough, this is about live operational knowledge.

Pick the closest answer.

Focus here next

Hosting and change safety

How the system is hosted, how code changes reach it, and whether changes are tested before going live.

How well known is the current PHP/runtime version?
Choose one

PHP versions go out of support on a schedule. An old or unsupported runtime is a security and compatibility risk that limits what can safely be changed. If nobody on the project knows what version the server runs, that uncertainty is itself a meaningful answer.

Pick the closest answer.

How clear and dependable is the hosting setup?
Choose one

Think about whether the hosting is transparent and recoverable, who controls the server access, whether the configuration is documented anywhere, and whether it could be moved or restored if something went wrong. A setup that only one person fully understands is an operational risk, not just an inconvenience.

Pick the closest answer.

How do code or system changes usually go live?
Choose one

Think about what actually happens when a change needs to go live, not the process that should exist. If someone manually edits files on the live server, uses FTP, or relies on one developer who does it their own way, that is the answer here.

Pick the closest answer.

How often are changes tested before they go live?
Choose one

Any kind of check before going live counts, a staging environment, a quick preview on a test page, even a brief manual review. If changes typically go directly to the live site without any kind of preview step, that is Rarely.

Pick the closest answer.

Focus here next

Data, backups, and recovery

Where important data actually lives, how recoverable it is, and whether its structure is understood well enough to move or repair safely.

Where does the important content or business data actually live?
Choose one

Pick the closest answer.

How confident are you that usable backups exist?
Choose one

A backup that runs on a schedule is not the same as a backup that can be restored on short notice. If someone says "yes, backups run nightly" but nobody has confirmed the files actually restore cleanly, that is Some confidence at most.

Pick the closest answer.

Has restore actually been tested?
Choose one

A backup that has never been tested is still an unanswered question. If the last restore was years ago, undocumented, or never happened, pick "Backups exist, but restore is untested". Not sure is also valid and it pushes the recommendation toward caution.

Pick the closest answer.

Is the data structure documented well enough to move, repair, or validate?
Choose one

This is asking whether anyone can describe the database tables, content types, or data relationships clearly enough to safely export, import, or repair the data. If a developer would have to reverse-engineer it from scratch, that is partial documentation at best.

Pick the closest answer.

Have exports, sample imports, or migration steps ever been tested?
Choose one

This is about whether anyone has tried to get the data out of the system in a usable form, even once, even roughly. If nobody has exported a database backup or tested what a content import looks like on a new platform, the answer is No.

Pick the closest answer.

Focus here next

Day-to-day operations

How much of the daily update work depends on spreadsheets, manual steps, awkward publishing flows, or needing a developer to make routine changes.

Where do routine content, catalogue, or admin updates actually happen?
Choose one

Pick the closest answer.

How usable is the current admin or publishing flow?
Choose one

Think about the experience of the person doing routine updates. If they regularly have to ask a developer, worry about breaking something, or work around the system to get things done, that is fragile or developer-gated, not just awkward.

Pick the closest answer.

Which fragile workflow patterns are true today?
Select all that apply

Pick everything that currently applies. If none are true, pick "None of these". If you are unsure about one or two, skip them, partial answers are still useful here.

Pick all that apply. If none fit, leave it blank or choose the explicit "none" option when present.

What feels like the main problem right now?
Choose one

Pick the closest answer.

Focus here next

Business dependency

What the system directly touches in the business and what the real cost would be if it stalled, broke, or became too slow to change.

What does this system directly affect?
Select all that apply

Pick all that apply. This is about real-world dependency, not technical complexity.

Pick all that apply. If none fit, leave it blank or choose the explicit "none" option when present.

How often does this system need changes or updates?
Choose one

Pick the closest answer.

If it breaks or goes down, what is the likely impact?
Choose one

Pick the closest answer.

Focus here next

Change pressure

What people are already pushing for, and whether there is enough clarity and control to act on it safely.

What are people currently leaning toward?
Choose one

This is about what has come up recently in internal conversations, meetings, emails, or planning discussions about what to do with this system. If there is no clear internal direction yet, "Still unsure" is the right answer.

Pick the closest answer.

Is there a deadline or outside pressure shaping this decision?
Choose one

This includes hosting platform end-of-life notices, contract renewals, compliance requirements, business milestones, or stakeholder expectations. If pressure exists but the reason is genuinely unclear internally, that is worth noting.

Pick the closest answer.

What best describes the pressure behind change?
Choose one

Pick the closest answer.

See how a similar system reads

Need a reference point before you keep going? These example systems show how different situations lead to different first moves. Use them to calibrate your own answers, not as a template to force-fit your situation.

Useful for orientation. Secondary to the actual assessment.

Answer at least 6 question groups to unlock the first-move recommendation.

Once enough signal is in place, the report appears here with a recommendation, rationale, next steps, and a copyable summary. "Not sure" answers are valid, they lower confidence, but uncertainty is itself a risk signal and often points toward the safer first move.