James Altucher was, in early 2011, one of the more prolific financial writers on the open web — author, investor, columnist on TheStreet.com, and a prominent voice inside the StockTwits® community where his blog reached a large audience of traders and entrepreneurs. The work was a WordPress® platform migration for jamesaltucher.com, coordinated with Phil Pearlman, then StockTwits’ chief psychology officer, who was managing the broader StockTwits Blog Network buildout. Altucher was listed as a contributor on that network, placing this engagement inside the same 2010–2011 ecosystem cluster that included the Lindzon site and several others. Completed January 2011.
The unromantic part is the load-bearing part
The visible deliverable of a WordPress migration is the site at its new home. The load-bearing work is the dozen unglamorous things underneath: the DNS (Domain Name System) records, the MX (Mail Exchange) records, the database dump and search-and-replace pass over serialised PHP data, the file-permission re-application after the upload, the test passes against staging, the kind of pre-flight checklist a senior practitioner runs because they have seen what happens to anyone who skips it.
The classic failure mode of a WordPress migration is not the WordPress part. It is the email part. A client’s email lives on the same domain as their website. The DNS record that points the website to its new home is the same DNS record that, if you handle it carelessly, routes the client’s inbox into the void for the next twenty-four hours. A site owner whose business runs on email — a financial writer who corresponds daily with publishers, sources, and readers, for example — does not want to wake up to a silent inbox the morning after their site moved.
The migration for jamesaltucher.com ran in early January 2011 with the email-safety pass at the top of the checklist, before anything touched DNS. That ordering — make sure the things that live alongside the site survive the move, then move the site — is the sentence most migration projects do not lead with, and most migration clients later wish they had. The mailing list, the calendar subscriptions, the single-sign-on integrations, the webhook receivers, all live on the same DNS zone as the website; all need to be accounted for before anyone changes a record. That work happens before the work the client thinks they are paying for, and a real practitioner builds it into the engagement without making it the client’s problem.
- Platform: WordPress (migration)
- Period: January 2011
- Client: James Altucher
- Coordinated with: Phil Pearlman, then chief psychology officer, StockTwits
The same risk surface, anywhere
Any production site migration carries this same risk surface. Political campaign, e-commerce store, healthcare practice, law firm, professional association. The visible thing the client is buying is the new site. The thing the practitioner has to protect is everything else that lives on the same domain and the same DNS zone. Email is the most common casualty, but it is far from the only one. The senior judgement is knowing the failure modes ahead of time and writing them into the project plan before anyone touches a record. The email sentence I led with in 2011 is the same email sentence I would lead with on a migration today, because the underlying risk has not changed.
The migration was carried forward as a portfolio reference in a 2018 client list. This entry rebuilds the record from that source.
