This serverless readiness checklist scores one workload on 14 checks. First, it asks whether the workload suits functions. Then it asks what must be true before it runs in production. Each check names its evidence and its owner. Also, the score gives one of four verdicts: Launch, Repair, then launch, Repair, then re-score, or Rethink the model.
Last reviewed 2026-11-14 by Manish Sharma.
A function-based service runs your code only when something calls it. That makes a function that runs only when called very different from a server that waits. The checks below suit a workload the team has already proposed for AWS or Azure. In that case, the question is whether to proceed, fix gaps first or choose another model. Serverless production readiness is a matter of evidence, not belief, so every check asks the team for something you can see.
Serverless Readiness Checklist: Marks, Scores and Verdicts
To begin with, every check gets one of three marks. Witnessed means the reviewer saw it on a run or in a record, Asserted means the team says so and nothing is seen yet, and Unbacked means there is no answer.
Then the serverless readiness checklist turns those marks into points: Witnessed is 2, Asserted is 1 and Unbacked is 0. The three fit checks give a top score of 6, while the eleven go-live checks give 22. Together, they give 28.
| Mark | What counts as evidence | Points |
|---|---|---|
| Witnessed | A run, a log or a record the reviewer opened | 2 |
| Asserted | A statement from the owner, with nothing opened yet | 1 |
| Unbacked | No answer, or an owner not yet named | 0 |
Score the three fit checks before the rest. If the fit score is 4 or more, the work continues to the eleven go-live checks. If the fit score is under 4, the verdict is “Rethink the model”, a separate topic that this guide does not cover.
Then read the go-live score. When the score is 18 or more, the verdict is “Launch”. A score of 12 to 17 is “Repair, then launch”: list every Asserted and Unbacked mark and fix them. If the score is under 12, the verdict is “Repair, then re-score”.
The order of reading matters. Checks G7 (permissions) and G8 (data location) must each reach Witnessed before the verdict can be Launch. If either one is Asserted or Unbacked, the verdict stays at “Repair, then launch” at best, and the score cannot lift it.
The go-live total does not decide alone: G7 and G8 must each be Witnessed before the verdict is Launch.
Serverless Readiness Checklist: Does the Work Suit Functions?
A good launch plan does not repair a poor fit, so fit comes before go-live. These three checks answer when to use serverless for the workload in front of you. In plain words, they ask for short work, started by a request or an event, with load that comes and goes.
| Check | Evidence to ask for | Owner |
|---|---|---|
| F1 What starts the work | A list of triggers from the design: each is a request or an event, short and independent of other runs | Application owner |
| F2 Length of one run | The longest run from logs or the design, set against the provider’s current run-time limit | Lead developer |
| F3 Traffic pattern | A week of requests by hour | Application owner with platform lead |
If you score F2, read the limit on the AWS Lambda quotas page and the Azure Functions hosting and scaling page. As of 14 November 2026, the AWS page lists a function timeout of 15 minutes. The Azure page gives a default and a maximum timeout that depend on the hosting plan, and it sets 230 seconds as the longest an HTTP-triggered function can take to respond. Then write the limit and the date read beside the check.
For F3, spiky or occasional load suits functions, but flat all-day load needs a closer look. Signisys working view: a flat load is not a failed check, but ask the team to show why a server would cost them more effort than a function.
Serverless Readiness Checklist: Four Groups of Go-Live Checks
When fit holds, eleven checks cover go-live. They fall in four groups: what the function remembers, how it behaves in busy hours, who may touch what, and running it after launch. Also, each table gives the evidence and the owner.
The checks run from G1 to G11, while the groups follow the order a launch plan needs. Ask for the evidence column first, and then the owner’s view.
What the Function Remembers
A function starts clean each time, so anything it must remember lives elsewhere. Also, these three checks cover that memory.
| Check | Evidence to ask for | Owner |
|---|---|---|
| G1 State held outside the function | A design note naming the store | Lead developer |
| G2 Database connection plan | How many functions may connect at once, set against the database’s own connection limit | Database administrator |
| G3 Safe repeats | A replayed event leaves one result, and failed messages land in a named queue | Lead developer |
G2 covers the case where many functions starting together can open more connections than a database allows. The AWS page on Amazon RDS Proxy describes a proxy that pools and shares database connections. It is one option to weigh for this check. For G3, a platform may deliver the same event twice. However, the second delivery must not double an invoice or an email.
How It Behaves in Busy Hours
These checks cover what users feel when load rises. A cold start is the added wait when a function wakes from idle. It hurts on a call a user is waiting for.
| Check | Evidence to ask for | Owner |
|---|---|---|
| G4 Cold start on a user-facing call | The measured first-call delay, set against what the user accepts | Product owner |
| G5 Concurrency ceiling | The account or subscription limit read from the provider page, and the setting on each function | Platform lead |
| G6 One load rehearsal at expected peak | The results, filed with the checklist | Quality lead |
For G5, the AWS page lists 1,000 concurrent executions per Region as a default that can be raised, and notes that new accounts start with reduced quotas. Meanwhile, the Azure page gives maximum instance counts by hosting plan. However, G6 is the only load test on this list. One rehearsal at the expected peak is enough to Witness the busy-hour checks, but a second rehearsal adds work, not marks.
Key Takeaway One rehearsal at the expected peak is enough to Witness the busy-hour checks.
Who May Touch What
Permissions and data location carry the order-of-reading rule from the first section. Each must reach Witnessed before the verdict can be Launch.
| Check | Evidence to ask for | Owner |
|---|---|---|
| G7 Permissions, secrets and input | A reviewed permission list per function, secrets held in a managed store, input checked before use | Security lead |
| G8 Data location for India and the GCC | The region setting, and where logs and backups sit | Security or compliance lead |
However, this guide names no residency or retention rule. If your team cites a rule, ask for its primary source. Until then, G8 is a question the owner answers with a record.
Ask the owner to open the region setting and the log location, not to describe them.
Running It After Launch
The last three checks cover the weeks after go-live, when the team, not the design, keeps the service healthy.
| Check | Evidence to ask for | Owner |
|---|---|---|
| G9 Logging and tracing across functions | One request followed from start to finish | Platform lead |
| G10 Team skills | Named people who can run and fix it, and an on-call plan | IT head |
| G11 Spend forecast and alert | How spend is forecast, and an alert switched on; no figures in the file | Finance partner with platform lead |
Serverless Readiness Checklist: One Workload Scored End to End
This example is illustrative and is not a Signisys project. The workload is an invoice-intake job that starts when a file lands in storage.
| Check | Mark | Reason |
|---|---|---|
| F1, F2, F3 | Witnessed on all three | Trigger list, run length and a week of requests all opened |
| G1 to G3 | Witnessed | Store named, replay tested, queue exists |
| G4 to G6 | Witnessed | Delay measured, limit read, one rehearsal filed |
| G7 | Asserted | Permission list promised, not yet reviewed |
| G8 | Witnessed | Region setting and log location opened |
| G9 | Witnessed | One request traced end to end |
| G10 | Asserted | Two people named, no on-call plan yet |
| G11 | Witnessed | Forecast method and alert shown |
Fit scores 6 of 6, so the work moves to go-live. Nine Witnessed marks and two Asserted marks give 20 of 22. A score of 20 clears the 18 line, yet G7 is Asserted. Then the order of reading applies, and the cap keeps the verdict at “Repair, then launch”. Then fix two items: the permission review, which the security lead owns, and the on-call plan, which the IT head owns.
Use this example to see how the serverless readiness checklist reads a good workload that still needs two repairs.
Key Takeaway A score of 20 still gives Repair, then launch while G7 is only Asserted.
Turning a Low Score Into Next Steps
Work through Asserted and Unbacked marks in a fixed order, and then score again after each batch. Permissions and data location come first, then state and safe repeats, then the busy-hour checks, then the running checks.
Signisys working view: re-score after each batch, not at the end, because a fix in one group can expose a gap in the next. Keep the file of evidence next to the score, so the next reviewer can open each item.
However, a fit score under 4 is different. It means another model may suit the work better than functions. For that decision, see a review of your own application and team for picking a runtime model.
Reading Before You Decide
Three short pointers sit beside this guide.
- the problems to plan for before moving a workload to functions covers the risks that sit behind several checks.
- the build order once the checks are met covers the build steps.
- A general modernization assessment and prices are separate topics, and this guide leaves them out.
This guide takes its limits from the AWS Lambda quotas page, the Azure Functions hosting and scaling page and the AWS page on Amazon RDS Proxy. The links for all three sit above. Providers revise limits, so read them again on the day you score.
Signisys provides this work. See how Signisys builds serverless applications on AWS and Azure, our application modernization and observability solution and DevOps and automation support. A working session starts from your own workload and your own evidence, but it promises no outcome. No charge, with a fixed scope.
Serverless Readiness Checklist FAQ
How long should the scoring take for one workload?
Does a high fit score mean the launch plan can be thin?
Which owner signs the data location check?
What if the team is new to the platform?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.