The Old Ejari That Was Never Cancelled — Why the New One Won't Register

This is The Ejari Desk. General information for Dubai, not legal advice. Ejaries.ae is a private service operated by Cendale Documents Clearing Services FZCO. It is not a government website, is not affiliated with the DLD or RERA, and does not issue Ejari certificates — certificates are issued through the official DLD and RERA systems.

A new tenancy contract does not automatically remove the previous tenancy record. Where the old Ejari remains active, the new registration can stop before it begins.

The contract and the registry are different records

The previous tenant may have moved out. The keys may have been returned. The landlord may already have signed a new lease. None of those events, by itself, proves that the old Ejari record has been cancelled. Ejari is the registered tenancy record, and a new tenancy cannot be treated as the first record if the system still sees an active one for the same property and period.

Diagnose before submitting again

Start by checking the status of the previous registration. Obtain the old Ejari number or certificate if available; confirm its dates, tenant and cancellation position. Do not keep uploading the new contract in the hope that the system will choose the newer document. A rejection or block is information — it usually tells you that the old record must be dealt with through the correct cancellation route.

Cancellation depends on status

Dubai Land Department provides cancellation channels through Dubai REST, the Ejari system and trustee centres. The approval and documentary position can differ depending on whether the contract remains valid or has expired, and whether the applicant is the landlord, the tenant or an authorised representative. This is why a one-line instruction to "cancel the old Ejari" is incomplete: you first need to know who can act, whether approval is required, and which record proves the tenancy has ended.

Sequence the two files

Close the previous record. Confirm the status. Then submit the new tenancy with the current owner, tenant, property and contract details, and keep the cancellation evidence with the new registration file. The new tenant should not carry the administrative cost of an old record that was never closed, and the landlord or manager should make the property record ready before promising an immediate new certificate.

A practical file example

A new tenant signs a lease and uploads a complete application. The system rejects it because the former tenant's Ejari remains active. The old tenant moved out months ago, so everybody assumes the record should have disappeared automatically. It did not. The new contract may be perfectly valid, but the property record still contains an unresolved tenancy event.

The file should be split in two. First establish the old contract, its end date, the move-out evidence and who can request cancellation. Then close that record through the supported route. Only after the property is administratively available should the new application proceed. Re-uploading the new lease without resolving the earlier record simply reproduces the same rejection.

Before anyone acts, reduce the file to a sequence: start with the contract and the registry are different records, move through diagnose before submitting again and cancellation depends on status, and finish with sequence the two files. That order matters because a later document cannot repair an earlier identity, authority or status gap. Write the steps down, put the source beside each step, and if one step is still based on an assumption, the file is not ready to move forward.

The terminology also needs to stay precise. The important expressions here — active Ejari, tenancy cancellation, previous tenant, new registration — are not interchangeable labels; each points to a different fact, record or administrative action. If a client, broker, bank or counter uses a broader phrase, translate it back into the precise question. Precision at the beginning prevents the team from collecting documents that look relevant but do not answer the receiver's requirement.

Use a stop rule, not a guess

There are three predictable failure points here. First, assuming move-out automatically cancels the Ejari. Second, submitting the new contract repeatedly without checking the old record. Third, trying to cancel while using the wrong applicant or missing the required approval or authority. None of these should be solved by optimism. The stop rule is simple: when a material name, date, amount, authority or property field does not align, pause the next irreversible action. Do not release money, book completion, cancel a live record, or submit another version merely to see whether the system accepts it.

A pause does not mean the transaction has failed. It means the unresolved point has been isolated while the parties can still correct it cheaply. Record the mismatch in one sentence, identify the document that should answer it, ask the person responsible for that document, then restart from the point at which the evidence becomes complete. That is faster than allowing an uncertain file to travel through several systems and trying to unwind it afterwards.

Keep an evidence trail another person can follow

Save the official output, not only a screenshot of the screen that produced it. Keep the date of the check, the fields entered and the result, and put the current identity, authority and property documents in the same folder. If a document is replaced, mark the older version as superseded rather than leaving two apparently current copies. A clean file should let another administrator understand the position without a telephone explanation. This matters when the case crosses from one organisation to another: a bank may look at the financial condition, a trustee or service centre at registration readiness, a landlord, tenant, buyer or seller at payment and possession. Each receiver sees only part of the story; your file note should connect those parts and state which facts are confirmed, which remain outstanding, and who owns the next action.

Know what would change the answer

The conclusion in any administrative file is time-sensitive. A new owner can be registered, a mortgage released, a tenancy ended, an authority expired, contact details changed. So a check should be repeated when a material event occurs, when instructions change, or when the transaction has been delayed beyond the period the original evidence was gathered for — old evidence may be genuine and still be unsuitable for today's decision. Before closing the file, say the conclusion narrowly: state what was checked, on what date, against which source, and for what intended purpose. Avoid words such as "clear", "approved" or "guaranteed" unless the issuing authority itself has used them for that precise result. A careful conclusion is not weaker — it is more useful, because everybody knows exactly what can safely happen next.

This was The Ejari Desk. I'm Stephen. Thank you for listening.