Drag
loader

Contact info

Email
hello@ferressystems.com.au
Based in
Melbourne, Victoria

Follow us

Talk to the team
Talk to the team
All services // IT PROJECTS AND MICROSOFT 365

The project nobody wants to own

There is a list of IT jobs nobody has picked up, and the box in the storeroom running something important is only the one you can see.

Assessments, Active Directory and identity, networks and firewalls, servers and storage, Microsoft 365 and cloud migrations, architecture and hardening. If it is IT work with a beginning and an end, it is this. Scoped properly, delivered outside business hours, and owned end to end by the same team that scoped it.

Scope this with us
 Free: The cloud migration readiness checklist
// SOUND FAMILIAR

If two of these sound familiar, we should talk

The rest of this page covers what the work includes, what it produces and how it is priced.

01 Something critical runs on hardware nobody wants to touch, and the person who set it up left
02 A project has been quoted twice and started never
03 Your directory still has accounts for people who left years ago, and nobody is certain what they can still reach
04 The network was designed for the office you had five years ago, and everyone works around it
05 Your systems grew by accretion and now nobody can draw the diagram
06 Every project you have run has ended with a handover document and no one to ask
// THE SCOPE, BOTH SIDES OF IT

What this is, and what it deliberately is not

What this is

  • Scoped project work with a written outcome and a date
  • Environment and infrastructure assessments, so the decision comes after the evidence rather than before it
  • Active Directory and Entra work: builds, cleanups, migrations and tenant consolidation
  • Networks, firewalls, switching and wireless, designed and cut over out of hours
  • Servers, storage, virtualisation and backup, on premises or in the cloud
  • Cloud assessment and migration, including the messy legacy parts
  • Microsoft 365 tenant setup, migration between tenants, and the cleanup afterwards
  • Architecture and hardening done together, so the new thing is not born insecure
  • On-site delivery where the work genuinely needs hands on it

What this is not

  • Open-ended day-rate work with no finish line
  • Moving a mess somewhere new without fixing it
  • An ongoing agreement. The project stands alone
// THE ENGAGEMENT, START TO FINISH

What actually happens after you say yes

Typically two to eight weeks

A directory cleanup or a firewall replacement sits at the short end. A multi-site network rebuild or a full cloud migration sits at the long one. The scope document says which one you are, before you commit.

01

The conversation

You tell us the problem rather than the solution. We ask what breaks if this goes wrong, who depends on it, and what your actual deadline is driven by. No proposal yet.

02

Assessment

We map what you actually have, which is almost never what the documentation says. Dependencies, licences, accounts, data volumes, the integration nobody remembered. Whether the job is a migration, an identity cleanup or a network rebuild, this is where projects usually go wrong.

03

Scope and schedule

A written scope in plain English, built from what the assessment found: what we will do, what you will have at the end, what stays out, when anything disruptive happens, and the fixed price. You approve it before anything changes.

04

Build and test

The new thing gets built and tested alongside the old one rather than on top of it, whether that is a migrated environment, a rebuilt directory or a new network core. Hardening is part of the build. You get to see it working before anything depends on it.

05

The change itself

Cutovers and switch-overs happen on a weekend or overnight, with a rollback plan written before we start. Smaller changes go in during the day where they genuinely carry no risk, and the scope says which is which. Your team arrives to something that works.

06

Handover

Documentation that someone other than us can read, a walk-through with your people, and a named contact who was actually on the project. Anything being replaced gets decommissioned properly rather than left humming in a cupboard.

// WHAT YOU WALK AWAY WITH

Things you can hold, forward and act on

The artefacts this work produces, named so you know what you are buying.

Written document

Environment assessment

What you actually have, dependencies included, before any work is proposed

Written document

Scope and schedule

Plain English, fixed, with what is explicitly out of scope named

The thing itself

The delivered system

Built, hardened, tested and cut over, with a rollback plan that existed beforehand

Written document

As-built documentation

Readable by your next provider, not just by us

Live walk-through

Handover session

With the people who did the work, not an account manager

// NOT A MOCK-UP

The questions that catch migrations out

A page straight out of the cloud migration readiness checklist, shown as it is. Read the page, then decide whether the whole document is worth an email address.

Cloud Migration Readiness SECTION 02 OF 12 // THE DEPENDENCY SWEEP

A common cause of failed cutovers is a dependency nobody documented. Work through these before scoping, not during.

ASK OF EVERY SERVER
  • What else authenticates against this server, including devices and printers
  • What scheduled tasks or scripts run against it, and who wrote them
  • Which reports, spreadsheets or dashboards pull data directly from its database
  • What has a hard-coded IP address or server name pointing at it
  • Which supplier or third party connects to it, and do they know it is moving
  • What certificates are installed, and when do they expire
THE ONE PEOPLE MISS HIGH

Hard-coded server names inside spreadsheets and reporting tools. They do not appear in any inventory, they belong to finance rather than IT, and they break on the Monday after cutover in a way that looks like the migration failed. We have found one of these three weeks after a project everyone had already declared a success.

HOW TO FIND THEM

Firewall and connection logs over a full month, not a week, because month-end processes are exactly the ones that only run at month end. A month still will not surface quarterly reporting, annual reconciliations, financial-year rollover or an audit extract that runs once, so ask about those separately rather than trusting the logs alone.

READY TO PROCEED WHEN PASS

Every observed inbound connection over at least 30 days is accounted for and owned by a named person, quarterly, annual and financial-year jobs have been checked separately because a month of logs will not show them, and each owner has confirmed in writing that they know the date.

Fillable workbook · 17 pages Read the rest of this page
Send me the checklist
// WHAT IT COSTS

Fixed price against a written scope

The assessment is quoted first, then the project at a fixed price from what it finds, so the number is based on what you actually have rather than on a phone conversation. If the job is bigger than expected, you hear that before you commit.

Get a written scope
WHAT MOVES THE NUMBER
How many users, sites and systems are involved
Whether the existing system has an upgrade path or needs rebuilding
How much of the data has to move, and how little downtime it can take
Whether hardening and remediation are bundled in or scoped after
Whether the work needs people physically on site
// FROM THE FILE

One of these, in the field

DECLASSIFIED

The server in the storeroom, and the spreadsheet that nearly broke the cutover

A migration quoted twice and started never. The assessment found eleven undocumented dependencies, including a finance spreadsheet pointing at the server by name that would have failed at month end, three weeks after everyone declared the project a success.

Read the case file
// QUESTIONS, ANSWERED

Asked before signing anything

No. Migrations come up often because they are the job most commonly put off, and the case study below is one. The same team does assessments, identity, networks, servers and storage, Microsoft 365 tenant work and hardening. If it is infrastructure work with a defined beginning and end, it fits here.

Yes, and it is common. Plenty of projects run with us delivering the work and the incumbent staying on for day-to-day support. Who does what is written into the scope, and nobody has to be replaced.

Yes. The assessment is scoped and quoted first, then the project is quoted at a fixed price from what it finds. If it finds something worse than expected, you hear about it in writing, with options and what each one costs, before you have committed to the project.

No. Project work stands alone and the documentation is deliberately written so another provider could pick it up. If you do want us to keep running it afterwards, that is a separate conversation about managed services, and it happens after the project, not as a condition of it.

The build and testing happen alongside your live environment, so almost nothing is visible until the cutover, and the cutover is scheduled out of hours. Any part that cannot be done invisibly is named in the scope.

// OFTEN SCOPED TOGETHER

What usually comes with this

Security Assessments and Penetration Testing Find it before someone less friendly does Security Assessments and Penetration Testing, scope and pricing
Cybersecurity Governance and Compliance Evidence is a folder, not a scramble Cybersecurity Governance and Compliance, scope and pricing

Tell us the problem, not the solution.

Get in touch
Shapes Shapes