Let's break down your illustrative sentence:
Users can delete Servers
This statement describes a capability -- users can perform this action. I'm hard-pressed to imagine how a different tense could be used here. Some technical writers (or style guides) make this overly passive -- "the system supports user deletion of servers" or some such. Speaking from 20+ years of experience in the field I say: don't do that. It's harder to read, harder to translate, and cumbersome without cause.
that do not have Customers assigned to them.
This looks like a present-tense verb ("do not have"), but its function here is as a description of state. What is important is that these servers do not, at the time that a user tries to delete them, have customers. This is perfectly acceptable. You may sometimes see "...that have not had Customers assigned to them" instead;1 do whatever is consistent with the documentation set your work is part of. (Possibly there's a house style guide that calls this out, but you may just have to read other examples to determine this.) I have only anecdotal evidence here, but I've found that the "present" formation ("do not have") leads to better reader comprehension (measured in requests for help) than the "past" formation ("have not had").
Technical documentation, unlike some other forms of writing, speaks to the reader in the present -- he has a problem to solve and he consults the documentation to find out what to do. Technical documentation is usually imperative ("do X"), and trying to combine the imperative mode with past tense can get confusing. You will still use "past-flavored" phrases like "after you have done X", or "if you have previously done Y", but the main thread of your documentation will make the most sense to readers in an imperative/present style as I've described (and as you've naturally gravitated toward).
(This answer applies to English-language technical writing. I'm not qualified to address other languages.)
1 Technically this is not an equivalent statement; if the system allows customers to be assigned and then un-assigned, then a server might have had customers assigned but still not have customers assigned (at the present time). If you're going to use the "past" formation, make sure this does not render your documentation incorrect!