#migration #static-site #markdown #github

$entry

Migration

$content = [

Migration from JourneymanJourneys to Notes.Gazali

Moving from JourneymanJourneys.com to Notes.Gazali.one

The move from JourneymanJourneys.com to Notes.Gazali.one was not about branding or visual redesign. It was about eliminating fragile dependencies.

The first version of the site revealed how easily writing can disappear when it sits inside systems you do not control.

The first domain

JourneymanJourneys.com was the first domain I ever bought.

Like many early projects, it went through several cycles. Launch, abandonment, expiration, and eventually reacquisition.

The original version was built on a hosted CMS. It worked while I maintained the hosting account. When the hosting expired, the entire site disappeared.

The posts were gone as well.

The root problem was architectural. The content lived inside the hosting environment and inside a CMS database. When the hosting account vanished, the database went with it.

That design made the writing dependent on infrastructure.

The no-CMS rule

For the new setup I imposed a simple constraint.

No CMS.

Content management systems solve publishing convenience, but they introduce structural dependencies:

  • Databases
  • Plugin ecosystems
  • Version compatibility issues
  • Platform lock-in

More importantly, they mix content with infrastructure.

If the system fails, the content becomes difficult to extract.

The goal of the new setup was to reverse that relationship. Content should exist independently of whatever system displays it.

Markdown as the canonical format

All posts are now written in Markdown.

Plain text. No proprietary formats.

That decision seems small, but it changes everything.

Markdown files remain readable with nothing more than a text editor. They migrate easily between tools. They also integrate naturally with version control.

Each article is just a file sitting in a repository.

Nothing is trapped inside a database.

Removing the hosting dependency

Instead of relying on traditional hosting, the repository lives on GitHub.

That changes the resilience model.

If the hosting platform changes, the Markdown files remain intact. If the site generator changes, the content still exists. If I move the site elsewhere, the migration is simply moving files.

The content is upstream from the infrastructure.

The SaaS compliance problem

There is another structural risk that often gets ignored.

When you depend heavily on SaaS platforms, you operate under their Terms of Service.

A complaint, whether legitimate or malicious, can trigger moderation or suspension. In many cases the platform may disable access first and investigate later.

At that point the burden shifts to the user to demonstrate compliance.

Even if the issue is eventually resolved, your site could remain offline during the process.

For personal publishing, that is an unnecessary layer of risk.

Reducing SaaS dependency reduces that exposure.

Minimal SaaS

The new system follows a simple rule.

Minimal SaaS.

Modern websites often accumulate layers of services:

  • hosted CMS platforms
  • analytics services
  • comment systems
  • newsletter integrations
  • plugin ecosystems

Each layer adds complexity and introduces another point of failure.

The new setup removes most of them.

The system is essentially:

  • Markdown files
  • a Git repository
  • a static site generator

Nothing more is required.

Security by simplicity

There is also a security benefit.

Most web attacks target application layers:

  • login pages
  • databases
  • API endpoints
  • form submissions

A static site removes most of those targets.

There is no login page. There is no database. There are no dynamic queries.

Without a database, there is nothing to inject. Without an authentication system, there is no login surface to attack.

The site simply serves static files generated from Markdown.

Even denial-of-service risk is mitigated because the site is delivered through Cloudflare, which absorbs traffic spikes before they reach the origin.

The architecture deliberately minimizes the attack surface.

Migration plan

The transition will happen in stages.

Both sites will remain operational during the migration period. Existing posts from JourneymanJourneys.com will be gradually ported over to notes.gazali.one, converted into Markdown where necessary.

Once the archive has been fully transferred, JourneymanJourneys.com will be permanently redirected to notes.gazali.one using a 301 redirect.

This ensures that:

  • existing links remain functional
  • search engines update their index correctly
  • the historical domain continues pointing to the new archive

The real objective

This migration was not about saving money or chasing performance.

It was about durability.

The first version of the site failed because the writing depended on infrastructure that eventually disappeared.

The new setup treats the writing as the primary asset.

Infrastructure can change. Hosting can change. Domains can change.

The content should survive all of it.

]