205 West 9th Street, Austin, TX 78701 +1 (804) 289-2596  ·  support@lios.mtechmpl.com  ·  Mon–Fri, 8:30 AM–6:00 PM CT
Home/Insights

Insights & field notes

Short, practical write-ups from the work we do. No gated downloads, no lead-capture forms — the whole article is on the page.

Cloud

Five questions to ask before your next Microsoft 365 migration

· 8 min read · by Daniel Johnson

Most failed migrations are not technical failures. They are scheduling and expectation failures. These are the questions we ask every client before we quote one.

  • What is the real size of your mail and file data, measured rather than estimated?
  • Which applications authenticate against your current directory, and who owns each of them?
  • What is the busiest week of your year, and how far can we stay away from it?
  • Who inside your organisation can approve a cutover decision at 9pm on a Saturday?
  • What does 'done' mean — mailboxes moved, or staff comfortable and old systems decommissioned?
Security

Multi-factor authentication is still the cheapest security you can buy

· 6 min read · by Daniel Johnson

Of the account compromise incidents we were called into during 2025, every single one involved an account without multi-factor authentication enabled.

  • Start with email, remote access and finance systems — in that order.
  • Use an authenticator application rather than SMS wherever the platform allows it.
  • Enrol shared and service accounts too; they are the ones attackers look for.
  • Publish a written exception process rather than letting exceptions happen quietly.
  • Re-run coverage reporting monthly, because coverage decays as staff change.
Consulting

What a technology assessment actually contains

· 7 min read · by Daniel Johnson

Assessments have a bad reputation because too many are sales documents in disguise. Here is the table of contents of ours, verbatim.

  • Asset inventory: every device, its age, warranty state and replacement year.
  • Licence position: what you pay for, what you use, what is duplicated.
  • Backup and recovery: what is protected, and the result of an actual test restore.
  • Security posture: findings ranked by likelihood and business impact, not by CVE score.
  • Twelve-month plan with costs, split into must-do, should-do and can-wait.
Operations

Why we publish our response targets

· 5 min read · by Daniel Johnson

Service level language is easy to write and hard to keep. We publish ours, and we report our performance against them every month whether the numbers flatter us or not.

  • Targets mean nothing without measurement, and measurement means nothing unless it is shared.
  • A missed P1 target appears in the client report before the client asks about it.
  • Two consecutive misses trigger an automatic escalation to the delivery manager.
  • We report median response, not average — averages hide the bad days.
Data

Spreadsheets are not the enemy

· 6 min read · by Daniel Johnson

Every reporting project starts with someone apologising for their spreadsheets. They should not. The spreadsheet is usually the clearest specification in the building.

  • The spreadsheet encodes rules nobody wrote down anywhere else.
  • Rebuild the logic first and the interface second, not the other way round.
  • Keep the old sheet running in parallel for one full cycle before switching.
  • Hand the model back with training, or you have simply moved the bottleneck.
Strategy

Budgeting for IT when you have never had to

· 9 min read · by Daniel Johnson

A practical framework for owners writing their first real technology budget, with the three categories we use and the numbers that usually surprise people.

  • Run: support, licences and connectivity — predictable, roughly 60% of spend.
  • Refresh: hardware replaced on a four-year cycle, budgeted as a quarter of the fleet per year.
  • Change: projects and improvements — the part that gets cut first and costs most later.
  • Add a 10% contingency. You will use it, and the year you do not is the year you buy something useful.

All articles are written by Daniel Johnson and reviewed by the engineer who ran the work described. If something here is out of date, tell us and we will correct it.

Have a question these notes did not answer?

Send it over. If the answer is useful to other people we will write it up — and you get the answer either way.