§ Kebehut vs migrating to a static site (lastupdate.site)

Migrating to a static site or keeping it dynamic with Kebehut.

Not every React or Next.js site actually needs to be dynamic. Some are marketing pages, documentation, brochure-ware, or blogs — content that was built as a single-page app out of habit, not out of need. When that's true, the honest answer is to migrate to a static site once and stop paying for maintenance entirely. lastupdate.site is the Skadi sister service that does this for legacy CMS sites (WordPress, Drupal, Joomla); the same logic applies to many React and Next.js sites too.

§ How migrating to a static site (lastupdate.site) is priced

Cost model.

One-time migration fee. For lastupdate.site: a single invoice for the conversion, then no hosting fees, no monthly maintenance, no renewal. Self-hosting the resulting static build on Cloudflare Pages, GitHub Pages, or similar is functionally free.

§ When each one actually wins

The honest split.

When Migrating to a static site (lastupdate.site) wins

  • The site is essentially marketing pages, docs, a blog, or brochure-ware that doesn't need server logic
  • There is no login, no per-user data, no real-time anything — and there isn't going to be
  • You'd rather pay once and be done than carry the codebase forward as a long-term liability

When Kebehut wins

  • The app has authentication, per-user data, or third-party integrations that need to live and breathe
  • The product is still evolving and you'll add genuinely dynamic features in the next year
  • The investment in being a real React or Next.js application is paying off in feature velocity

§ Side by side

Concrete differences.

Aspect Migrating to a static site (lastupdate.site) Kebehut
Cost shape One-time fee. Zero recurring cost after migration. No monthly invoices, no renewal cycle. Fixed monthly: 60€ baseline. Lower than the cost of one missed security advisory.
What you end up with A static build. No backend, no runtime, no monthly attention required. The same dynamic application, kept current month after month with a written record.
When you'd reverse the decision If the site later needs server logic, you rebuild — the migration is one-way by design. If the app turns out to not need to be dynamic, we'll tell you. The first month's report says so plainly.

§ FAQ

Questions, briefly answered.

Does lastupdate.site work on React or Next.js sites, or only legacy CMS?
Today it is productized for WordPress, Drupal, and Joomla. For React or Next.js sites, the same shape of migration is possible but is not yet a productized service. Email us — if a static migration is the right answer for your specific app, we'll point you at the right path, including back to lastupdate.site if applicable.
How do we tell whether our app could be static?
The first month of Kebehut Basic answers exactly this. The audit identifies which parts of the codebase actually need a runtime and which don't. If the honest answer is 'none of it needs to be dynamic', the report will say so and recommend a one-time migration over ongoing maintenance.
Is recommending a migration against Kebehut's interest?
Sometimes. We'd rather tell you the honest answer than keep an engagement we shouldn't have. The pilot phase is specifically about finding customers who genuinely fit Kebehut — pushing maintenance contracts at sites that should be static would erode that.

Tell us which side fits.

Email us a paragraph about the app and the situation. If migrating to a static site (lastupdate.site) is the right answer for you, we'll say so.

[email protected]