Responding To My Former Web Host, Part Three — The Finale

Responding To My Former Web Host TOC:

In part two I stated that I thought that would be the end of this series of posts, and yet here I am with part three. This one will be the absolute final post as I don't have anything more to say to my web host. However, the response I received just now really should be documented. I said in part two that I respected the people I worked with at this hosting company, and that continues to be the case.

So, with that, here is the last exchange.

My Response To The Support Person

Thank you for the response. You have largely understood the issues that I brought up, and had some insightful feedback.

I would like to clarify something, as I think I didn't provide a proper context for you.

At no point did I feel that the infrastructure was in my way. That is quite far from the case. I am actually a former IT Server / Infrastructure engineer. My understanding of your underlying design is why I decided to go with your service in the first place. I was tired of working with hosting services that really didn't understand how to implement a solid infrastructure. Even though there were aspects of the environment I didn't use, it was good to know they were available if I needed them. (And, if I had migrated one of my other sites, I am quite certain I would have needed them.)

My “using a sledgehammer when all I really need is a screwdriver” is typical of me. I've always tended to look at requirements / specs, and design solutions that are overkill.

The “optimization issue” was really only frustrating the first time it happened. Since I didn't have the familiarity with the codebase to know where to look for the issue I was left in a situation where I couldn't find the answer on my own. Once support had tracked down the issue, it was mostly just an infrequent annoyance, which is why I didn't make any noise about it. (If it had been a serious enough issue, I would have pushed the issue to your dev group.)

The only thing that really didn't fit for me is WordPress. I can tell you understand that level of frustration I am feeling with that. ;)

As to the pricing, while it wasn't a major issue for me, I did find it annoying. I would think that Enterprise customers would likely find it frustrating too. I know most of the places I worked preferred to be able to have fixed rate contracts for a given term, and then be able to re-negotiate when that term was up. This kind of pricing structure would likely have never flown in any of the environments I worked in. (OTOH — all the companies I worked for had their own infrastructure, and WordPress wasn't considered an Enterprise class platform.)

Response From My Former Web Host

Thank you for the clarification and for sharing more about your background.

That context definitely helps me better understand where you were coming from.

It’s great to hear that the infrastructure itself was actually one of the reasons you chose our service. I completely understand the “sledgehammer vs screwdriver” approach as well, especially from an engineering perspective where building for flexibility and scalability becomes second nature.

I also appreciate you clarifying the optimization issue. That makes perfect sense, especially when the main frustration was initially not knowing where to look within an unfamiliar codebase rather than the issue itself being critical.

And yes, I completely understand your feelings about WordPress. It can definitely become the limiting factor, particularly for users coming from more traditional infrastructure and engineering environments.

Your feedback regarding the pricing structure is also very valid. Predictability is important, especially in enterprise environments where fixed-term budgeting is often preferred.

Thank you again for the thoughtful feedback and for taking the time to explain your experience in more detail. We genuinely appreciate it.

Wishing you all the best,

What I Didn't Provide Detail About

When I said above:

And, if I had migrated one of my other sites, I am quite certain I would have needed them.

I was referring to the dev/test environment feature they offer. The site I haven't migrated relies heavily on a WordPress plugin that is no longer available. The company that produced it completely pulled it from the market, doesn't offer any support for it, and didn't bother to make the code available for it.

This left me with 250-350 posts that rely on a plugin that is no longer available or supported, with no clear migration path.

I've since dumped the contents of that site. All the information from that plugin is stored in metadata in each post. When I dumped it (into a Jekyll compatible flat-file format), all the metadata came along with the posts. Now I just need to extract that data from the JSON section of each file, and translate into an appropriate format for presentation here.

Along with this, I need to test all the URI's in the posts. Given the age of the posts, I know there are quite a few that are no longer available… This is going to be true for all ~500 posts on that site.

This is a task that is going to be annoying. I am going to have to find some way to automate it. Manual intervention isn't an option.

Conclusion

To summarize everything:

FediRing
◀️ Prev Home Next ▶️