I'm new to the Migration Tool and I'm having an issue deploying my managed package code to a developer org. The error I'm getting says:

The specified package namespace: NAMESPACE does not match the namespace for the server

Since namespaces are specific to an org is it possible to deploy this code?

Thanks, tim

  • To make your code as portable as possible, you do not need to explicitly namespace anything but code references in custom button actions and one other thing I can't remember. Within apex, you can just refer to classes and methods without the namespace however.
    – greenstork
    Oct 21, 2014 at 17:31
  • To add to @greenstork's answer, it takes some effort to keep the namespace out of your managed package components as some tooling automatically adds it. So you may have a cleanup job to do. But it is possible; we use Jenkins to push our managed package code (that operates under a namespace) into namespace-less orgs to ensure what we have under version control is consistent and complete.
    – Keith C
    Oct 21, 2014 at 18:12

2 Answers 2


We are using DevOrgs with different namespaces as part of our development process. I have described parts of it as an answer to Best practices for Versioning managed packages in Git. In our experience it is the best to:

  1. Never hardcode references to the namespace in your code. If the namespace is really needed, it could be determined by a custom object or field of your package and comparing getName() vs. getLocalName()
  2. Use a branch or something similar to separate your DevOrgs with different namespaces.
  3. Replace the namespace reference at the package.xml by something generic like <namespacePrefix>PREFIX</namespacePrefix> and replace it before deploy and after retrieve. The real namespace could be stored at the build.properties file
  4. Create a unique namespace for the target DevOrg before the first deployment and put it into the build.properties. We are using our JIRA story keys for that (e.g. FOO-2346 key results in FOO_2346 namespace).

As mentioned in comments, I'd say the best practice is to make your code able to run in a DE org as unmanaged metadata and at the same time deployable to a packaging org with the namespace.

Assigning a throw away namespace in DE orgs seems like a lot of overhead as you can only have one namespace per DE org. For our project, our developers each maintain their own DE org and reuse it from story to story and sprint to sprint.

One way we do that is with a utility class which checks if we are running inside a namespace and provides methods which can dynamically namespace strings.

I just did a theater session at Dreamforce focused on converting an existing unmanaged package project into an unmanaged development / managed release package. You can see all the changes I had to make to dynamically support namespace (check the UTIL_Namespace.cls) and wrap our build scripts around it here:


You can see the whole session recording here for more context though the dynamic namespacing is only a small part of the session: http://dreamforce.vidyard.com/watch/9qWCaabFMQY4G1yeUHJyCw

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .