search

WordPress / developer-blog-content

In this GitHub space, WordPress team coordinate content to be published on the Developer Blog. Discussion and montly meetings (first Thu) in WP Slack #core-dev-blog
36 stars 2 forks source link

Learnings from two Site Migrations #212

Closed bph closed 2 months ago

bph commented 5 months ago

Discussed in https://github.com/WordPress/developer-blog-content/discussions/209

Originally posted by **jewelsie** January 25, 2024 Hi there! I'm Jasmine, a digital project manager from Ohio. I've worked in software for almost a decade but do NOT have a technical background. I just completed the migration of two of my company websites from a headless CMS to WordPress and WOW did I learn a lot. I was wondering if this is a topic anyone would be interested in. I could talk to -Process best practices -Testing best practices -Plugins I found useful -Resources that were valuable -The benefit WP is giving us over our headless CMS
bph commented 5 months ago

Hi @jewelsie The topic was approved in today's Editorial Group meeting. However, it would be great to learn more about article you have in mind. Here are two pages to read:

And please comment on this issue, so we can assign it to you (GitHub is quirky that way)

jewelsie commented 5 months ago

Thanks Birgit! It's exciting to be considered!

I can whip up a more formal outline, but one idea I had was migration from a Scrum perspective (my background).

Sprint Planning Plan your migration before hand. Start with a crawl to know your pages. This will help you plan URL mapping AND break pages down into content types so you have an idea what types of blocks will need developed and what sort of plugins will need used. If you have any one-off content types, think of ways you could achieve these with more commonly used blocks to avoid developing a block you'll only use once.

Grooming This is where I worked closely with the development agency to understand HOW they were going to approach the blocks and we made adjustments for flexibility. Flexible blocks and flexible plugins were HUGE. Flexible blocks meant we needed to develop less blocks. One small examples, image / text blocks where I can quickly invert which side the image is on, select any H1-H6 header, and retain full control over the body content.

Stand-Up - We used thrice weekly stand ups to sync up with developers, and resolve any blockers / questions they had. We used slack for asynchronous communication which made communicating and executing super fast.

Kanban Board Not officially a Scrum artifact, I know. But it is how we managed our backlog and as a self-described Kanban Fanatic, I have to sing its praise. It really sped up the testing and review process.

Sprint Review If you think your plan covers it all, think again. Our stakeholders met weekly and gave feedback on the site so we could make changes DURING the process rather than waiting until the end.

Retrospective Knowing we were going to turn around and do it again on another site, we revisited the first migration and had honest talks about what went well, what could be improved. Changes to our Kanban board and communication processes came out of it.

Benefits, an anecdote: We have pages for outside vendors on our site. Occasionally we get a request to update their brand images, address, etc. Before migration, this process took a week to implement and deploy. We recently got one of these requests and deployed the changes in 15 minutes on WordPress!

If Scrum is too niche of a view, I'm happy to approach it a different way.

bph commented 5 months ago

Your earlier outline was much more concrete and relevant to more WordPress site owners, and builders. It wasn't anchored in a theory of Agile Project Management. The need for more details was more about the problems and how you overcame em and which plugins and resources you would mention.

jewelsie commented 5 months ago

Totally understand. I get a little too excited about scrum sometimes. I'll put together an outline that is more about the concrete tools I used.

justintadlock commented 5 months ago

Yeah, this was one of the concerns we had with approving this topic. Some of us wanted to make sure this was very specific to solving problems within WordPress. So anything you can do to really "bring it home" to WordPress devs/site-owners is going to be important.

Also, linking to third-party tools, plugins, themes, etc. is generally frowned upon (there are cases where it might be necessary, though). So, as you work through your outline, just keep that in mind.

bph commented 4 months ago

@jewelsie Were you able to continue working on this article? I wondered if we should discuss this on a Zoom call or so, to make sure you are moving forward.

jewelsie commented 4 months ago

@bph Actually a zoom call would be very beneficial. Being non-technical and so many of the existing WP developer blogs being highly technical, I'm stalled worrying I'm not going to provide what you need / want.

bph commented 4 months ago

We can certainly get on a call later this week or beginning of next week. Please use my public calendar to pick a date/time.

bph commented 2 months ago

After our meeting, we agreed that the topic approach wouldn't be suitable for the developer blog. @jewelsie, as discussed, I'd be happy to assist you in publishing your knowledge on a different site with less restrictions.